On Mon, 8 Jun 2015, Frank Meier wrote:

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.

I think it works fine because that is the only case documented where that value is used.

I've merged it like that now and if we come up with improvements we do that as follow-ups.

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 initially thought exactly the way you do here, but when I tried it out I even had a test case fail.

Since there has been a distinction we can't remove it without risking some breakage. I.e an application can set either or both sizes and only the actually used one is what matters. You can set both sizes then to first a POST and then a PUT without changing the set sizes and it'll work. Combining them into one storage area removes that ability and we risk breaking existing applications the same way I broke a test case when I tried it out.

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.

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?

It was introduced exactly like that so that old libcurls kept working and only newer applications that would use that feature would return that value and then it'd work. Returning that value with a too old libcurl will have it treated as an error.

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.

Yes they could!

In reality I think most users just write their applications to require version
= x.y.z and remain happy with that.

--

 / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Reply via email to