- From: Willy Tarreau <w@1wt.eu>
- Date: Thu, 9 Feb 2012 15:01:29 +0100
- To: Patrick McManus <pmcmanus@mozilla.com>
- Cc: Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
On Thu, Feb 09, 2012 at 08:55:10AM -0500, Patrick McManus wrote: > I definitely see whitespaces before responses now and again and tolerate > them as best as I can. Messing with that in a bis standardization update > seems to be an over reach. OK, thanks for the feedback. > I find it hard to believe a document change > would change any deployed behavior (as it introduces breakage without > upside in a legacy protocol) - so the spec would just be less accurate > which is pretty much the opposite of the bis charter goal. It's not that much a document change since it's already not allowed. Either we acknowledge that a number of tools don't accept them and don't have any issue and the text can remain as is, or we acknowledge that some implementers had to relax the rule so we'd need to clarify this in the spec. Right now you're saying that you had to implement something that is not covered by the spec, and *this* is embarrassing. I must say I did this in haproxy without realizing that the spec only allowed the leading CRLF in the request message. > this embarrassing nit is, however, a good example of why http/2 needs to > be binary framed. Too much energy is expended on the commodity activity > of parsing headers the current way. While binary framing can improve this, it is also much more complicate to debug and test by hand. However strict fixed-length elements could be a good improvement. Regards, Willy
Received on Thursday, 9 February 2012 14:02:14 UTC