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

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.

> 
> > 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.
> 
> 
> I think replacing "then" with "also" in the text is sufficient.
> 

It still leaves the question on which connection (upstream or
downstream) MUST be closed.

Regards,
  Dmitry

> Cheers,
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
>

Received on Saturday, 3 December 2011 13:48:43 UTC