- From: Willy Tarreau <w@1wt.eu>
- Date: Fri, 2 Dec 2011 21:39:13 +0100
- To: Alex Rousskov <rousskov@measurement-factory.com>
- Cc: Adrien de Croy <adrien@qbik.com>, Patrick McManus <mcmanus@ducksong.com>, ietf-http-wg@w3.org
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.
In my opinion it would be fair to ask that if a proxy internally uses a
header and it has to resort to specific tricks to interprete it correctly,
then it should at least fix it before forwarding it since it is supposed
to know the rules which apply to this header.
Regards,
Willy
Received on Friday, 2 December 2011 20:39:54 UTC