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

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.

>
> Should the specs require connection closure to prevent message smuggling
> in naive implementations that respond with an error to "reject the
> message" but then keep the connection open/persistent?  The specs are
> explicit about this in item #3 where they talk about "framing" error,
> but not here, where essentially the same framing error is suspected if
> the message is rejected.

Good point.

The text you quoted above from paragraph 4 is only talking about cases 
where the values are identical (ie correct), just duplicated.

    GET / HTTP/1.1
    Content-Length: 0
    Content-Length: 0
    Content-Length: 0,0
    Host: example.com

There is no request smuggling here. Other requests may be pipelined 
before or after it perfectly fine under the semantics of treating each 
requests independently.

The smuggling risk only rises where conflicting or incorrect values are 
sent, which is the case described in item #3.

AYJ

Received on Tuesday, 29 November 2011 05:46:38 UTC