Re: [#95] Multiple Content-Lengths

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

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

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.

-Eric

Received on Friday, 15 October 2010 03:26:38 UTC