Bugs item #2980877, was opened at 2010-04-02 03:25
Message generated for change (Comment added) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=2980877&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: http
Group: bad behaviour
>Status: Pending
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Anil Kumar (anilsf)
Assigned to: Daniel Stenberg (bagder)
Summary: CR at the beginning of header marks it as end of HTTP header

Initial Comment:
CR at the beginning of header marks it as end of HTTP header.
For example

print "HTTP/1.1 200 OK\r\n";
print "HHH1: v1\r\n";
print "HHH2: v2\r\n";
print "\rXYZ: vxyz\r\n";
print "HHH3: v3\r\n";
print "\r\n";

curl will treat '\r' at the beginning of XYZ as end of HTTP header and will finish header processing.

This bug is because of the following code at
http://github.com/bagder/curl/blob/master/lib/http.c#L3196
     /* headers are in network encoding so
       use 0x0a and 0x0d instead of '\n' and '\r' */
    if((0x0a == *k->p) || (0x0d == *k->p)) {
      size_t headerlen;
      /* Zero-length header line means end of headers! */

It should have been
    if((0x0a == *k->p) || ((0x0d == *k->p) && (0x0a == *(k->p + 1)))) {

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-04-06 23:38

Message:
Thanks for reporting this issue and helping us improve curl and libcurl.

We're awaiting feedback in this issue. Due to this, I have set the state
of this issue to pending and it will automatically get closed later on
unless we get further info.

Please consider answering the outstanding questions or providing the
missing info so that we can proceed to resolve this issue!

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-04-04 21:45

Message:
Are you saying that you're having a problem with a real live server that
sends such headers?

And what browsers have you tested this with?

----------------------------------------------------------------------

Comment By: Anil Kumar (anilsf)
Date: 2010-04-04 20:02

Message:
CR LF or LF is a line feed. Just CR is NOT line feed.

Try similar response in browsers, they do NOT treat CR LF CR as end of
http header.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-04-03 20:58

Message:
libcurl will assume two consecutive linebreaks to be the end of the
headers, and it is liberal in what a linebreak is. It can be CRLF, just CR
or just LF if I recall things correctly.

Apart from you trying to find a problem in libcurl, can you point out a
single server instance that would send headers like this and it would work
with any amount of ordinary browsers or HTTP clients? Until you can point
any such out, I will continue to believe that this is not legitimate HTTP
and libcurl will not treat it as a header.

----------------------------------------------------------------------

Comment By: Anil Kumar (anilsf)
Date: 2010-04-02 22:19

Message:
        generic-message = start-line
                          *(message-header CRLF)
                          CRLF
                          [ message-body ]
        start-line = Request-Line | Status-Line

without two consecutive CRLF it should not be considered as end of HTTP
header

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-04-02 20:57

Message:
Sorry, but a header cannot legally start with a CR, thus if the line starts
with CR it is no header...

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=2980877&group_id=976
Received on 2010-04-06