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

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

Now, whether the above was the intent of RFC 2616, and (if yes) whether
HTTPbis is allowed to make that intent explicit, I do not know.


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.


Cheers,

Alex.