Re: [#95] Multiple Content-Lengths

On Tue, Oct 12, 2010 at 09:38:57AM -0700, Adam Barth wrote:
> On Tue, Oct 12, 2010 at 9:21 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> > On 12.10.2010 18:13, Adam Barth wrote:
> >>>>
> >>>> I would say:
> >>>>
> >>>> "...If this is a response message received by a user-agent, it MUST
> >>>> be treated as error."
> >>>>
> >>>> (or at the SHOULD-level if you're scared of MUST-level requirements).
> >>>
> >>> Well, "MUST be treated as error" isn't really helpful; it doesn't require
> >>> any observable behavior.
> >>>
> >>> That a response message like this *is* broken is a statement of fact; the
> >>> question is whether we want to require any specific handling. So, for
> >>> instance, do we want to forbid any of the behaviors we see today? (use
> >>> the
> >>> first value/use the second value/use until end of connection)?
> >>
> >> I see.  I meant that the user agent MUST close the socket and ignore
> >> the response, or whatever the HTTP spec idiom is for instructing the
> >> user agent to treat this response as a fatal error.
> >
> > Yes. As a matter of fact, my proposal wasn't better in that aspect :-)
> >
> > So...
> >
> > "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."
> 
> SGTM.

I'm realizing that this is very similar to the chunked-encoding with
content-length. I wonder whether we have numbers on the cases where
this still happens, because the risks of bad handling are exactly the
same, even though the spec says that chunking must be assumed in this
case. It would be nice if numbers showed that we could simply consider
that situation as an error.

Regards,
Willy

Received on Tuesday, 12 October 2010 18:40:58 UTC