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

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.

Cheers,
Willy

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