bug#13598: 24.3.50

[Blazej Adamczyk <blazej.adamczyk@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1454 bytes --]

Ahh yes my mistake! I was looking at some wrong sources. Obviously the current "^\r?\n" is correct. 

Sorry and thanks!
Blazej

From Glenn Morris <rgm@gnu.org> w dniu 27 lut 2014, o godz. 23:43:

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.


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 495 bytes --]