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