W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2011

Re: Whitespace before responses

From: Dale Anderson <dra@redevised.net>
Date: Sun, 3 Jul 2011 19:11:49 -0700
Message-ID: <CANNRn6+qoVqOfAocpHDsjyvas1eeOmK-iy2DMkQUdXbP=G0ecw@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:43 GMT