Subject: Whitespace before responses

From: Mark Nottingham <[email-masked]>
Date: Thu, 30 Jun 2011 09:12:49 +1000

<http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-3.1> says:

   In the interest of robustness, servers SHOULD ignore at least one
   empty line received where a Request-Line is expected.  In other
   words, if the server is reading the protocol stream at the beginning
   of a message and receives a CRLF first, it SHOULD ignore the CRLF.

Should a similar approach be taken when clients parse responses?

See also:
  https://bugzilla.mozilla.org/show_bug.cgi?id=668168

--
Mark Nottingham   http://www.mnot.net/

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 30 Jun 2011 01:34:55 +0200

> Should a similar approach be taken when clients parse responses?

While I have done it in haproxy, I don't think it really adds any value,
as I don't remember having even seen a server emit extra CRLFs after a
response.

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.

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 ?

>   https://bugzilla.mozilla.org/show_bug.cgi?id=668168

Well, to be fair, I don't really catch the relation between this and
packet boundaries as discussed in this bug report. In my opinion, those
are two orthogonal things.

Regards,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 30 Jun 2011 10:28:55 +1000

> 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.

> 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.

> are two orthogonal things.

Re-read :)

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 30 Jun 2011 06:46:22 +0200

> 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…

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 ?

> 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

---

From: Daniel Stenberg <[email-masked]>
Date: Thu, 30 Jun 2011 09:46:28 +0200 (CEST)

> Should a similar approach be taken when clients parse responses?

I don't think so. I don't think HTTP has allowed this and I don't think we 
should soften this area now. I also have never gotten or seen a report similar 
to the Firefox one so curl doesn't accept an initial CRLF in a HTTP response.

-- 

  / daniel.haxx.se