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: Thu, 01 Dec 2011 09:17:44 -0700
Message-ID: <4ED7A8A8.6050101@measurement-factory.com>
To: Mark Nottingham <mnot@mnot.net>
CC: ietf-http-wg@w3.org
On 12/01/2011 03:30 AM, Mark Nottingham wrote:
> 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


Absolutely, but the question paused by this thread remains: Are proxies
_required_ to fix messages they forward? Or are they just required to
interpret the messages they receive correctly? The HTTPbis specs do not
give a clear answer, IMO, and should be adjusted one way or the other.

I can propose specific wording changes if it helps but (a) I do not want
to spend time on that if there is consensus that the current wording is
good enough and (b) I need to know which way to polish (to require fixes
or remove the implication that they are required).


Thank you,

Alex.



> 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 16:18:48 GMT

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