[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#13598: 24.3.50
From: |
Blazej Adamczyk |
Subject: |
bug#13598: 24.3.50 |
Date: |
Mon, 3 Mar 2014 07:10:21 +0100 |
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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#13598: 24.3.50,
Blazej Adamczyk <=