#1441 Handling of 4-digit HTTP response code

[Balaji]

1. According to the HTTP documentation RFC-2616, status code should be only 3 digit integer.
   http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1.1
2. When I requested a URL using libcurl, in the response I received “HTTP/1.1 1064” response with 1064 as status code and following error:
   “libcurl error code 56: Illegal or missing hexadecimal sequence in chunked-encoding”
3. The observations of response and cause of above error is :
   a. When I request a URL (I can’t provide it) using libcurl, I received response status
   code is: “HTTP/1.1 1064” i.e. (1064 - You have an error in your SQL syntax; check the
   manual that corresponds to your MySQL server version for the right syntax to use near……..”)
   b. Libcurl parses only first 3 digits of status code in “CURLcode
   Curl_http_readwrite_headers()” method present in “libcurl/http.c” file.
   c. Due to parsing of initial 3 digits only from status code (.i.e. in my case 106 from
   1064); header parsing logic fails in the above method, resulting into above mentioned
   libcurl error.
4. Also when I request the URL using curl command line, I did not observe the libcurl error.
5. Status code parsed by curl command line is also: 106.
   I.e. Output of: curl --write-out %{http_code} --silent --output /dev/null <url>
   is 106.</url>
6. I also requested the same URL in Chrome, Mozila and IE browsers, they handle it properly and shows response code as “1064 OK”.

Why libcurl silently ignores the invalid status code received from web server?
Is it possible to scan all 4 digits from status code to resolve above libcurl error?

System Details:
Curl version: curl 7.12.1 (i686-redhat-linux-gnu) libcurl/7.12.1 OpenSSL/0.9.7a zlib/1.2.1.2 libidn/0.5.6
OS : Linux

[Daniel Stenberg]

Thanks for your report, even though you use a version that is over 10 years old.

I cannot repeat the problem 2.

The only bug I see here is that libcurl only parses the 3 first digits of the number so any longer number gets truncated. I have a fix for this now pending, but I consider this a very mild bug since that's not even legal HTTP.

[Daniel Stenberg]

Fix pushed to git now. It now returns >3 digit codes too, and I also added 5 new tests that verify the HTTP response line somewhat for a few crazy variations.

Thanks!

[Balaji]

Thanks Daniel for quick fix.
I checked your code changes implemented as a part of this fix on git.
I think, we might need to handle HTTP status code which is more than 3 digit long returned from NCSA 1.5.x too.

[Daniel Stenberg]

Really? Then please submit a patch, and please also add a test case or two since I doubt we ever test that response format currently!