- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 02 Dec 2011 21:50:42 +0100
- To: Willy Tarreau <w@1wt.eu>
- CC: Alex Rousskov <rousskov@measurement-factory.com>, Adrien de Croy <adrien@qbik.com>, Patrick McManus <mcmanus@ducksong.com>, ietf-http-wg@w3.org
On 2011-12-02 21:39, Willy Tarreau wrote: > On Fri, Dec 02, 2011 at 10:21:42AM -0700, Alex Rousskov wrote: >> If we state that, an HTTP proxy would have to make a choice when dealing >> with a "broken" incoming message: >> >> 1) reject the malformed message >> 2) forward a "fixed" message >> 3) forward raw bytes, becoming a TCP tunnel >> >> Currently, many interpret HTTP specs as if there is another option: >> >> 4) forward the malformed message "as is" >> while interpreting it correctly internally. > > Actually, it's even more common to see this : > > 5) ignore 90% of headers you don't care about and for which you > don't know how to determine the validity, and apply 4) when > you care about the header. > > I don't see how we can impose 2) for the 90% headers that a proxy > does not understand and just ignores. > ... The reason being that some header fields are special and essential for message framing/routing. If HTTP/1.1 had been defined from scratch, Host and Content-Length probably wouldn't be in the same part of the message as other metadata...
Received on Friday, 2 December 2011 20:51:18 UTC