- From: Dale Anderson <dra@redevised.net>
- Date: Sun, 3 Jul 2011 19:11:49 -0700
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CANNRn6+qoVqOfAocpHDsjyvas1eeOmK-iy2DMkQUdXbP=G0ecw@mail.gmail.com>
Apologies, I put below message onto the wrong thread. Happy 4th of July, I knew something would blow up.. pow, there goes my email credibility! Dale 2011/7/3 Dale Anderson <dra@redevised.net>: > 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 Monday, 4 July 2011 02:12:16 UTC