Re: Whitespace before responses

On Thu, Jun 30, 2011 at 10:28:55AM +1000, Mark Nottingham wrote:
> 
> On 30/06/2011, at 9:34 AM, Willy Tarreau wrote:
> > That said, skipping leading CRLFs can be quite cheap but can bring a new
> > issue for browsers who try to detect HTTP/0.9 responses.
> 
> We've deprecated HTTP/0.9, so while it still might be encountered in the wild, implementations aren't required to support it, and we shouldn't prioritise its operation over good behaviour in HTTP/1.x.

I totally agree on this. After all, it's not even possible to retrieve a
file beginning with "HTTP/1." over HTTP/0.9, and it might even be dangerous.
So why support it as a fall-back at all ?

> > Probably that we should check if any client implementation supports it
> > first, and decide not to take this approach if nobody does it right now ?
> 
> See the Moz bug; as I read it, they already support it if the response isn't fragmented.

This is a bug or a design error in my opinion. No assumption should be made
about how data are received over a TCP connection. The response should be
interpreted exactly the same if it comes one byte at a time or if it comes
as a single block. Even after re-reading it, I still don't get why there
are two possible interpretations depending on this.

In my opinion, either the UA accepts CRLFs before a response and should
skip all leading CRLFs until there is something different, or it does
not accept them and should not do that in only one case. We cannot rely
on isolated bytes from a partial stream to decide which version is being
reported. Otherwise I suppose that we can have the same breakage if
"HTTP/1.1" is sent one byte at a time, and this is wrong.

Regards,
Willy

Received on Thursday, 30 June 2011 04:46:49 UTC