cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: libcurl misses end of request data before reading response (patch)

From: Frank Meier <frank.meier_at_ergon.ch>
Date: Mon, 08 Jun 2015 14:46:47 +0200

On 07/06/15 23:55, Daniel Stenberg wrote:
> Aha. Thanks for clarifying and sorry for being slow.
no worries :-)
> If I understand your problem correctly, this will fix the problem as
> long as the post size is known right?
Yes that's right. Your patch looks fine to me. I think the distinction
that 'set.filesize' is only considered as 'state.infilesize' if
'set.httpreq' is HTTPREQ_PUT is a bit strict, but ok. In my opinion
CURLOPT_POSTFIELDSIZE and CURLOPT_INFILESIZE could be substitutes of
each other, therefore we could internally skip distinguishing between
the two (e.g only set 'set.filesize' and drop 'set.postfieldsize'), but
perhaps I miss some cases were the distinction matters.
> I would rather consider a way to introduce an EOF flag so that a
> callback can actually say "here are the final N bytes of data". Like
> for example allowing a callback to OR the return value with 0x20000000
> and treat that bit as EOF. Of course that'd break all older libcurls
> but would be made to work with a libcurl supporting this! What would
> you think about that?
I like that!
About breaking the compatibility with older libcurls, I think it is the
same as when the other "special" return codes like CURL_READFUNC_PAUSE
were introduced. Where there any special steps taken then? Further I
think it is not that bad, since the user could check the curl version
from inside the callback, to decide which return codes/flags are available.

cheers, Frank

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2015-06-08