Re: [#95] Multiple Content-Lengths

On Sep 19, 2010, at 10:57 PM, Mark Nottingham wrote:

> I've been talking to a few browser vendors about this off-list (and encouraging them to get involved on-list).
> 
> Two have indicated that they intend to implement as specified, although there's some agreement that a duplicate C-L can be ignored, as Willy has implemented.
> 
> There have also been questions about the text seeming to encourage implementers to display the content when there are mismatching C-L's; although it's written so they're not required to do so, it might be good to refine this a bit.
> 
> Two replied that they have concerns about displaying errors to end users. If they come on-list and discuss their concerns, we can discuss this more.
> 
> One hasn't replied.
> 
> Based on those discussions, I'm reopening issue #95, and making a straw-man proposal to kick off discussion:
> 
> Current (-11): 
> 
>   3.  If a message is received without Transfer-Encoding and with
>       either multiple Content-Length header fields or a single Content-
>       Length header field with an invalid value, then the message
>       framing is invalid and MUST be treated as an error to prevent
>       request or response smuggling.  If this is a request message, the
>       server MUST respond with a 400 (Bad Request) status code and then
>       close the connection.  If this is a response message received by
>       a proxy or gateway, the proxy or gateway MUST discard the
>       received response, send a 502 (Bad Gateway) status code as its
>       downstream response, and then close the connection.  If this is a
>       response message received by a user-agent, the message-body
>       length is determined by reading the connection until it is
>       closed; an error SHOULD be indicated to the user.
> 
> Proposed:
> 
>   3.  If a message is received without Transfer-Encoding and with
>       either multiple Content-Length header fields indicating different
>       lengths or a single Content-
>       Length header field with an invalid value, then the message
>       framing is invalid and treated as an error to prevent
>       request or response smuggling.  If this is a request message, the
>       server MUST respond with a 400 (Bad Request) status code and then
>       close the connection.  If this is a response message received by
>       a proxy or gateway, the proxy or gateway MUST discard the
>       received response, send a 502 (Bad Gateway) status code as its
>       downstream response, and then close the connection.  If this is a
>       response message received by a user-agent, it SHOULD NOT
>       be used, but if it is the message-body
>       length is determined by reading the connection until it is
>       closed, and the user SHOULD be informed of the problem. 
>       Subsequent responses on the connection MUST NOT
>       be used.

I don't have a problem with the first change (duplicate headers
being allowed) or "Content-Length: n, n".

The latter changes don't work.  "it" is ambiguous, and
"SHOULD NOT be used" is a new requirement that no current browser
supports AFAIK.  And there are no subsequent responses on the
connection because the framing no longer works -- they all get
folded into that one response because the message length is
determined by connection close [in practice].

I did not specify any specific choice of how a user agent
might inspect the stream and make a safe choice about which
of the lengths actually work for that response because, AFAIK,
none of them do so now.  I'd love to be proven wrong about that
by a sudden desire of user agents to conform to a single behavior.
I don't think we can require anything more than it SHOULD be
indicated as an error.

....Roy

Received on Monday, 20 September 2010 22:52:01 UTC