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

On 04/12/2011, at 12:47 AM, Dmitry Kurochkin wrote:

> Hi Mark.
> 
> On Sat, 3 Dec 2011 11:28:32 +1100, Mark Nottingham <mnot@mnot.net> wrote:
>> 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?
>> 
> 
> (There is a long discussion in this thread on this.)
> 
>> 
>>> 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).
> 
> I think this depends on the result of the discussion on the first
> question.  If a proxy is required to correctly interpret duplicate CL
> values, then there is no framing problem and connection should not be
> closed.  But if a proxy can interpret duplicate CL as invalid and reject
> the message, then it can not correctly determine the message length and
> MUST close the connection.

You're requiring us to make a false choice. The current text allows the proxy to choose whether to reject the message or to replace the value, but does not require the connection to be dropped. I.e., it's an error, but not a framing error.

Are you arguing that duplicate C-L is a framing error? If so, we can have that discussion, but let's separate it from the other concerns here.


>>> 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.
> 
> The above question is related to the sentence (quoted below) about
> handling an invalid upstream response by a proxy.  So there are both
> upstream and downstream connections.

[...]

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

Ah.

That seems quite straightforward; your proposed text seems fine.


Thanks,


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

Received on Monday, 5 December 2011 02:13:48 UTC