- From: Dale Anderson <dra@redevised.net>
- Date: Sun, 3 Jul 2011 16:24:34 -0700
- To: mnot@mnot.net
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
Hi Mark, > Should a similar approach be taken when clients parse responses? I think so, yes. Clients and servers should both ignore extra CRLF. Even if the client and the server are are both netcat/stdio the client or server at their station might want to hold down the enter button to make some clear room on their terminal. Similarly and with regards to your section 3.1, I like the way this first paragraph reads Mark then.. > Some old HTTP/1.0 client implementations send an extra CRLF after a > POST request as a lame workaround for some early server applications > that failed to read message-body content that was not terminated by a > line-ending. An HTTP/1.1 client MUST NOT preface or follow a request > with an extra CRLF. If terminating the request message-body with a > line-ending is desired, then the client MUST include the terminating > CRLF octets as part of the message-body length. I think the text reads better without giving the flawed example implementation. In the interest of robustness, client and server applications that are expecting to read a request or response line should not abjure all hope and connections if the line is empty (just CRLF). Try again, your request-line will come, don't abort this connection.. Regards, Dale Anderson
Received on Sunday, 3 July 2011 23:25:08 UTC