curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: cunked transfert-Encoding without content length

From: Daniel Stenberg via curl-library <curl-library_at_cool.haxx.se>
Date: Fri, 20 Dec 2019 13:25:01 +0100 (CET)

On Fri, 20 Dec 2019, GENESTIER Denis via curl-library wrote:

> Since the curl version 7.58, the chunked Transfer-Encoding response that
> contains a negative content length are considered as invalid.

*All* responses that contain Content-Length and Transfer-Encoding are invalid.
Or in the words of RFC 7230 section 3.3.2:

    A sender MUST NOT send a Content-Length header field in any message
    that contains a Transfer-Encoding header field.

> These kinds of message seem correct to me (cf
> https://en.wikipedia.org/wiki/Chunked_transfer_encoding?oldid=430331176) and
> I may considering this as a regression from curl.

I don't understand what you refer to. What part in that wikipedia article
would indicate that this is a legitimate HTTP response?

I'm pretty sure a lot of other HTTP clients will also similarly go nuts on
such a response.

> Actually I have to specify the option CURLOPT_IGNORE_CONTENT_LENGTH, to
> maintain the curl integration in my code to communicate with our legacy
> server. Is there any ways to adapt this behavior in the file http.c, to not
> take in account a negative content length in case of chunked response?

Historically, we once supported negative content-lengths (without chunking)
because some servers in the early 2000s would do that when serving larger than
32 bit contents.

We removed that work-around as you say before 7.58.0 was released. Worked on
in this PR: https://github.com/curl/curl/issues/2212

Landed in this exact commit: https://github.com/curl/curl/commit/f68e6727158
(in January 2018).

To me, it sounds like CURLOPT_IGNORE_CONTENT_LENGTH is the perfect rememdy for
this case. It is a HTTP violation to send both headers, but you can make curl
put up a blind eye for that if you're willing to take the consequences - with
a special option.

Or am I missing something?

-- 
  / daniel.haxx.se | Get the best commercial curl support there is - from me
                   | Private help, bug fixes, support, ports, new features
                   | https://www.wolfssl.com/contact/
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html
Received on 2019-12-20