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

I don't see it that way.  If the intermediary owns the TCP connection to 
the client, it is the emitter.

HTTP explicitly prohibits sending multiple Content-Length headers.

Therefore an intermediary must not send more than one.  Regardless of 
what it receives.


On 29/11/2011 7:38 p.m., Willy Tarreau wrote:
> Hi Amos,
>
> On Tue, Nov 29, 2011 at 06:45:56PM +1300, Amos Jeffries wrote:
>> On 29/11/2011 3:05 p.m., Dmitry Kurochkin wrote:
>>> Hello.
>>>
>>> HTTPbis part 1 section 3.3 has the following requirements:
>>>
>>>    If more than one Transfer-Encoding header field is present in a
>>>    message, the multiple field-values MUST be combined into one
>>>    field-value, according to the algorithm defined in Section 3.2, before
>>>    determining the message-body length.
>>>
>>>    If a message is received that has multiple Content-Length header
>>>    fields (Section 8.2) with field-values consisting of the same decimal
>>>    value, or a single Content-Length header field with a field value
>>>    containing a list of identical decimal values (e.g., "Content-Length:
>>>    42, 42"), indicating that duplicate Content-Length header fields have
>>>    been generated or combined by an upstream message processor, then the
>>>    recipient MUST either reject the message as invalid or replace the
>>>    duplicated field-values with a single valid Content-Length field
>>>    containing that decimal value prior to determining the message-body
>>>    length.
>>>
>>> It is not clear whether proxies that do not reject the message MUST
>>> replace the duplicated field-values in the forwarded message.  In other
>> How is "MUST ... replace the duplicated field-values with a single valid
>> Content-Length field" unclear?
>>
>>> words, are non-transforming proxies required to either reject or fix the
>>> message?
>> Yes. "MUST either ... or ...."
>>
>> Depends on your philosophy IMO. If you want to be hardline and prefer
>> reject over header alterations its allowed.
> I understand Dmitry's point. I think he's using a proxy which is more a
> gateway in fact, which does very few things and just tries to stay in sync
> with the stream and to avoid alterations as much as possible. That's what
> is one in IPS, load balancers or any product which needs to read HTTP
> without being intrusive. I've had the same experience with haproxy, where
> HTTP was added as minimal processings on top of TCP before being improved
> with time.
>
> My personal rule of thumb on this is that if you don't touch anything, you
> can't make things worse ; if you find that there is a real danger in what
> you see, you should close ; if you find that what you read is not perfect
> but should cause no risk (at worst just fail), then it's better not to
> alter the stream.
>
> In his situation, there is a difference between the interpretation of the
> content-length and modifying it before forwarding it. If his product is
> just forwarding the TCP stream and not producing the headers, he's not
> violating the HTTP specs (otherwise routers would be too). However if he
> detects something abnormal he can't understand, it would seem quite dangerous
> to ignore it and let it pass.
>
> Regards,
> Willy
>
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Tuesday, 29 November 2011 07:52:00 UTC