On 2006-05-31, Daniel Stenberg wrote:
> On Wed, 31 May 2006, Daniel Moore wrote:

> If we for a while assume we wanted to add this feature to the lib, how
> exactly do you propose it would work?

First of all, I assume the existing behaviour would have to remain
default, so add a new CURLOPT_SPLITMULTIPART to request multipart splitting.

So we receive a request, pass it on to the server and start receiving a
response. We pass the header on as usual to CURLOPT_HEADERFUNCTION. The
header contains the multipart type, which lets us and the consumer know
we're expecting multiple parts.

After the header comes a boundary marker, then the header for the first
part. This header is just like the standard http header, so pass it back
to CURLOPT_HEADERFUNCTION just like you do for chunked trailers.
_Hopefully_ the sender will have sent a content-length, so remember it.
Otherwise we'll need to scan for the boundary in the data.

Then read data & send it back to CURLOPT_WRITEDATA as usual, but watch
for either the appropriate number of bytes received (content-length) or
for the multipart boundary. When the end of the part is detected, return
from curl_easy_perform, having stashed away any remaining data read from
the stream.

At this stage, we've read the first part of a multipart in a single call
to curl_easy_perform, and returned to the caller.

We could return a special error code indicating when there are more
parts to come eg CURL_OK when we're done or CURL_OK_MOREPARTS if we
expect more.

Basically I'm thinking when we're between parts, it's a lot like when
we're between requests on a normal stream... ie we can return to the
caller and let them call back. If the stream is dropped in the meantime,
that's their tough luck.

> libcurl currently has no support for anything like this so it would require
> new stuff. You up to working on it/suggesting how it would work?

I wrote a libcurl based http video capturer for our product with the
intention of replacing our existing home-brew solution. The libcurl
version is really simple and nice, except that it doesn't support
multipart streams. So if I got more time in the future to work on that
code, and libcurl people were happy with that approach, I'd probably
work on pushing multipart support into libcurl rather than into my
capturer.

At the moment, as is the way of these things, I'm back working on other
things, so all I could do for now is offer suggestions...

Regards,
Daniel Moore
Received on 2006-06-01