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

Hi Amos.

On Tue, 29 Nov 2011 18:45:56 +1300, Amos Jeffries <squid3@treenet.co.nz> 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?
> 

I am concerned about the "prior to determining the message-body length"
part.  It may be interpreted as the proxy must remove duplicate header
values for it's internal use only (i.e. to determine the message-body
length) and can forward unmodified message with duplicate headers.  Same
for TE header.  In other cases (e.g. item #2), the spec is explicit:
modify before forwarding downstream.

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

Indeed.  So even if proxy does not remove the duplicate CL values, it
still must correctly determine the message length per item #4 because
item #3 does not apply here.  In this case, "prior to determining the
message-body length" part in the paragraph 4 seems unneeded.

Regards,
  Dmitry

> AYJ
>

Received on Tuesday, 29 November 2011 06:36:34 UTC