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: Alex Rousskov <rousskov@measurement-factory.com>
Date: Fri, 02 Dec 2011 14:50:13 -0700
Message-ID: <4ED94815.8060909@measurement-factory.com>
To: Willy Tarreau <w@1wt.eu>
CC: ietf-http-wg@w3.org
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.
Received on Friday, 2 December 2011 21:51:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:50 GMT