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

Hi Dmitry,

On 29/11/2011, at 1:05 PM, 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
> words, are non-transforming proxies required to either reject or fix the
> message?

My reading is that they must. Roy?


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

I don't think that's required here, because the values are duplicates (as discussed).


> Also, should the specs be more specific regarding what connection
> (upstream or downstream) proxy is required to close?

There is no upstream connection at this point; in this context, the proxy hasn't started to forward the request yet.


>  If this is a response message received by a proxy, the proxy MUST
>  discard the received response, send a 502 (Bad Gateway) status code as
>  its downstream response, and then close the connection.
> 
> Above can be interpreted that the downstream connection must be closed.
> But the proxy should only close the upstream connection.  Moreover, the
> "then" word is wrong there as there is no need to keep that connection
> open while the 502 response is being sent.  The order of those actions
> should be up to the proxy to decide.
> 
> The fixed text may read:
> 
>  If this is a response message received by a proxy, the proxy MUST
>  discard the received response, close the upstream connection, and send
>  a 502 (Bad Gateway) status code response as its downstream response.


I think replacing "then" with "also" in the text is sufficient.

Cheers,

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

Received on Saturday, 3 December 2011 00:29:00 UTC