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

I think that's where we left it.

This style of implementation often changes the stream; e.g.,

  Connection: close
to 
  Connxxtion: close

and similar. Likewise, implementations like those discussed could do:

  Content-Length: 100,100
to
  Content-Length: 100    <-- whitespace

Cheers,


On 30/11/2011, at 2:58 AM, Alex Rousskov wrote:

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

--
Mark Nottingham   http://www.mnot.net/

Received on Thursday, 1 December 2011 10:31:18 UTC