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: Tue, 29 Nov 2011 08:58:04 -0700
Message-ID: <4ED5010C.4030306@measurement-factory.com>
To: ietf-http-wg@w3.org
On 11/29/2011 06:32 AM, Willy Tarreau wrote:
> On Tue, Nov 29, 2011 at 11:55:56PM +1300, Adrien de Croy wrote:
>>
>>
>>
>> I can understand why someone would code some software that way, but I 
>> don't think it's correct to call that a proxy.  At least it's not HTTP 
>> compliant.
> 
> I 100% agree with you, that's why I stated that it was more of a gateway than
> a proxy.
> 
>> It could be argued that strategy of proxy operation is simply not valid.
> 
> Agreed too! The term "proxy" is often used when connections are
> re-established (TCP proxies) but I regularly repeat that in the HTTP
> terminology that's not enough to be called a proxy. An HTTP proxy is a
> well-defined entity that cannot simply be assumed by a TCP proxy.


The scope of this thread question is not a TCP proxy. The core of the
concern is a regular HTTP proxy. Some HTTP proxies prefer to forward
message headers "as is" when possible rather than always recreating the
forwarded message from internal metadata. Such proxies may still be
compliant and interoperable if the specs are clear when it comes to
forwarded message manipulation.

The current requirements do not make it clear whether a compliant HTTP
proxy may, for example, leave "Content-Length: 100,100" in the message
it forwards while correctly interpreting that header as "Content-Length:
100". The uncertainty exists because the requirement uses the word
"replace" but talks about message interpretation (which does _not_
require changing the forwarded message).

  Requirement: MUST replace the duplicated field-values with ...
  Scope or timing: prior to determining the message-body length.

Possible solutions:

1) If the intent is to require that proxies fix messages they forward,
then the requirement should be polished and split into two:

  MUST interpret the duplicated field-values as ...
  MUST replace such Content-Length header(s) with ...

2) If the intent is to require correct interpretation without mandating
message fixes, then the requirement should be polished by changing
"replace with" to "interpret as".


What was the intent? Do we want to require all proxies to fix malformed
Content-Length headers in forwarded messages?


Thank you,

Alex.
Received on Tuesday, 29 November 2011 15:59:14 GMT

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