Re: clarify some MUST requirements in HTTPbis part 1 section 3.3

Hi Julian,

On Fri, Dec 02, 2011 at 09:50:42PM +0100, Julian Reschke wrote:
> 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.

I perfectly agree on this point. What it also means is that a proxy which
has to respect message framing will have to interprete those headers and
will then know their semantics and how to fix them, which does not seem
to contradict the previous proposal. Still it could be argued that not
trying to fix them will avoid making things worse (which unfortunately is
too true in some environments).

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

Indeed, as well as Connection and Transfer-Encoding. Still they exist now
and the fact we're naming them implies they have a more important role than
the other ones. Maybe something like this would make things clearer for
proxy authors (with a better wording) :

  When a proxy faces a malformed header, it must either reject the message
  or fix the header before forwarding it. This applies to all headers the
  proxy cares about for its processing, and in any case to Connection,
  Content-Length, Host and Transfer-Encoding.

Regards,
Willy

Received on Friday, 2 December 2011 21:11:40 UTC