Re: [#95] Multiple Content-Lengths

On Oct 14, 2010, at 8:26 PM, Eric J. Bowman wrote:

> Maciej Stachowiak wrote:
>> 
>> Julian Reschke wrote:
>> 
>>> Adam Barth wrote:
>>>> ...
>>>>> "If this is a response message received by a user-agent, it
>>>>> SHOULD be treated as in error by ignoring the message and closing
>>>>> the connection."
>>>> 
>>> 
>>> I've made it say:
>>> 
>>> "If this is a response message received by a user-agent, it SHOULD
>>> be treated as an error by discarding the message and closing the
>>> connection."
>>> 
>>> (<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1031>)
>> 
>> Is there a reason for this to be a SHOULD instead of a MUST? I know
>> Adam already asked that, but I don't recall seeing an answer.
>> 
> 
> While MUST would be correct for a browser-conformance specification, it
> isn't in scope for HTTP to dictate what user-agents do with responses,
> only how to interpret them.

Requiring clients to close the connection seems in scope to me. Though to be fair, the requirement for the very explicit "Connection: close" directive is only SHOULD-level.

> If I'm debugging a server using curl, I
> want to see duplicate or incorrect Content-Length headers instead of
> total failure.

Debugging is a special case. I would not be inclined to wrap the whole spec around it.

That being said, it seems like a debugging tool would be entitled to report the error, including multiple Content-Lengths, but it would also be required to close the connection immediately and to not present the message as if it were a normal valid response.

> 
> This isn't a security problem in my development environment, access to
> which isn't possible over the Internet, so I'd rather be able to debug
> without resorting to wireshark because all user-agents are required to
> be as paranoid as a desktop browser.  My preferred wording:
> 
> "If this is a response message received by a user-agent, the message-
> body length MAY be determined by reading the connection until it is
> closed; an error SHOULD be indicated to the user."

Phrasing it like that sounds like a recipe for interoperability failure. Furthermore, it doesn't even list the option that we seem to have rough consensus is the best behavior for browsers.

> 
> To me, that implies that it's up to the user-agent to decide whether to
> discard the message, or allow it to complete; either way is an error.
> 
> I understand the security problem, but something which in reality
> occurs in an undetermined subset of responses (different Content-
> Lengths) which altogether only account for .001% of traffic (duplicate
> Content-Lengths) is not justification for SHOULD discard -- which would
> downgrade debugging tools like curl to being only conditionally
> conformant, an outcome which just isn't justified.

The security risk is not proportional to the frequency of the problem on the live internet. However, the need for debugging is proportional to the frequency. So if the problem is very rare, the tradeoffs should be in favor of security. (That's assuming the security risk is indeed serious; I do not know enough about the relevant attacks to judge).

Regards,
Maciej

Received on Friday, 15 October 2010 05:17:52 UTC