Re: got_chunk signal

[Bill Peck <bill pecknet com>]

Hi Dan,

Thanks for the suggestion.  I'm currently trying to clone the webkit repo to look for the example you mention.  I also looked at tests/multipart-test.c which shows several payloads separated by the boundary --cut-here\r\n.  Would this keep the connection open to my clients like it currently does?  I would be able to keep calling soup_message_body_append () as I read in data?

Thanks

On Mon, Sep 23, 2013 at 1:27 PM, Dan Winship <danw gnome org> wrote:

On 09/23/2013 11:26 AM, Bill Peck wrote:
>
> I have a question about the got_chunk signal.  I know the docs mention
> that it's not guaranteed to match the chunks the sender sent, but is
> there a way to fix that?
>
> I'm sending chunks from the server side prepended with a 1 byte char
> that represents where to send the output to (stdout or stderr) but as
> you might have guessed I sometimes have a chunk from the server broken
> into two parts by the receiver.   tcpdump confirms that I am getting it
> as one message from the server so I don't understand why libsoup
> sometimes (not always) breaks it into multiple chunks.

There's no way to make libsoup guarantee that it will emit the same
chunks that the server sends, but your protocol shouldn't depend on
being able to do that anyway; if the user is using a proxy, then the
proxy might re-chunkify the data as well. Chunking isn't part of the
response, it's just an aspect of how the response is transferred from
server to client.

One supported (and semi-standard) way to do what you want is to send a
response body of type multipart/x-mixed-replace, and have each response
be a new body part. On the client side you can then use
SoupMultipartInputStream to split up the response into the right pieces.
(There's example code of this somewhere in the WebKit sources...)

-- Dan