On Fri, Aug 28, 2009, Milmar Tan wrote:

> I can't set the write callback before the header callback gets called
> because I haven't yet allocated the buffer that will hold the image at
> that time.

The write callback does not normally get called until *after* all the
headers have been received. When you get an empty header with just
the \r\n you'll know it's the last header, so if you haven't gotten
a content-length by then, you can return -1 to abort the transfer
from the header callback, before the write callback ever gets called.
But if you decide later to enable CURLOPT_FOLLOWLOCATION, things will
get even more complicated.

> I noticed that the headers were also being written to the
> buffer together with the image data

The reason your headers are being written to your data buffer
is because you set CURLOPT_HEADER to 1. Don't do that.

> My initial tests show the above hack works. But it's quite scary to
> suddenly get an error with the hack in place during production of the
> device.

Then my advice would be to find another way to accomplish your task.
There is really no point in fiddling with libcurl's internal state
while a transfer is in progress. What you want can certainly be
accomplished without that.

Also note that the "stream" pointer passed in to the callbacks
doesn't necessarily have to be a file descriptor, it can be a
pointer to whatever data structure you decide to create in order
to best suit your needs. You'll probably want to have some way
of insuring that you actually receive the amount of data that
the content-length advertised, else you'll be asking for a
buffer overflow.

Regards,

 - Jeff
Received on 2009-08-29