Daniel Stenberg wrote:
> On Sat, 11 Jan 2014, Cédric Deltheil wrote:
>
>> When performing a standard HTTP POST (w/o chunked encoding) with a custom
>> read function, a common mistake is to forget to explicitly set the POST
>> size via `CURLOPT_POSTFIELDSIZE`.
>>
>> This results in libcurl sending a negative content length:
>>
>> Content-Length: -1
>>
>> , which gives a bad request.
>>
>> The question is: should we prevent libcurl to send the request by failing
>> early?
>
> Yes I think so. Sending -1 is plain wrong.
>
>> Before sending a patch, I was wondering if `CURLE_UPLOAD_FAILED` would be
>> the best error code to use there.
>
> Sure. With a decent failf() as well it should be fine.

Just a comment from the sidelines. Although it is probably the closest code
for this error, CURLE_UPLOAD_FAILED seems wrong. In my mind, it implies a
wire error, whereas it would really be a library parameter/setup error. I
went looking for something akin to the UNIX EINVALID, but did not see that.
  Seems like a CURLE_[BAD|INVALID]_[SETUP|PARAMETER] (pick your name) would
be a good thing for this kind of situation. Or, if the road to a new return
code is taken, perhaps add more than one:

CURLE_MISSING_PARAMETER
CURLE_INVALID_PARAMETER
CURLE_INCONSISTENT_PARAMETER

Probably the first two would do. More likely, a single code for 'you
screwed up, programmer!' would do.

Just my two cents,

Rich

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-01-12