GNU bug report logs - #13598
24.3.50; url-http.el doesn't correctly parse headers when they are sent line-by-line

Previous Next

Full log

Message #47 received at 13598 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Blazej Adamczyk <blazej.adamczyk <at> gmail.com>
Cc: 13598 <at> debbugs.gnu.org
Subject: Re: bug#13598: 24.3.50
Date: Thu, 27 Feb 2014 17:43:08 -0500

Blazej Adamczyk wrote:

> By example:
> When parsing response we may get in state when we will receive only
> the following:
>
> "HTTP/1.0 200 OK^M
> "
>
> without double quotes (I added them to show the newline character).
>
> In case of current implementation the regexp "^\r?$" and the previous
> regexp "^\r*$" both are matching the end of string. That is wrong
> because there will be something in the new line after a while.

The current implementation uses "^\r?\n", not "^\r?$".
Where did you get "^\r?$" from?

As such I do not see that it will match your example.

> RFC 2616 states clear:
>        generic-message = start-line
>                          *(message-header CRLF)
>                          CRLF
>                          [ message-body ]
>        start-line      = Request-Line | Status-Line
>
> there has to be one (exactly one) CR in a single line between headers
> and body. Thus I propose a simple regexp "^\r$".

Yes, but as I already quoted in

http://debbugs.gnu.org/13598#17

it also recommends tolerance:

   The line terminator for message-header fields is the sequence CRLF.
   However, we recommend that applications, when parsing such headers,
   recognize a single LF as a line terminator and ignore the leading CR.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.