W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2011

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

From: Willy Tarreau <w@1wt.eu>
Date: Fri, 2 Dec 2011 23:06:12 +0100
To: Alex Rousskov <rousskov@measurement-factory.com>
Cc: ietf-http-wg@w3.org
Message-ID: <20111202220612.GC27965@1wt.eu>
On Fri, Dec 02, 2011 at 02:50:13PM -0700, Alex Rousskov wrote:
> On 12/02/2011 02:11 PM, Willy Tarreau wrote:
> > 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.
> Since the concept of "caring about the header" is not (and cannot be)
> defined and "fixing the header" essentially means emitting a header that
> complies with the specs, I believe the above is pretty much equivalent to:
>   In the absence of requirements specific to proxies, when forwarding
>   an upstream message, an HTTP proxy MUST comply with requirements
>   for HTTP clients. Consequently, if the upstream message is
>   malformed, a proxy MUST NOT forward it "as is".

This is still as much ambiguous as what it currently is IMHO, because
everyone will have a good reason to consider that some fixing is not
under his responsibility.

> If we restrict ourselves to Content-Length handling, the above becomes:
>   When forwarding an upstream message with an invalid Content-Length
>   header, a proxy MUST NOT send a message with an invalid
>   Content-Length header to the next hop.
> followed by the current HTTPbis rules about appropriate reactions to
> some specific kinds of malformed Content-Length headers.

I like this one much better, it sets the focus on a clear action even
if it implies additional specific code in products.

Received on Friday, 2 December 2011 22:06:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:54 UTC