Re: Set-Cookie vs list header parsing (i129)

Brian Smith wrote:
> 
> That isn't what the spec says, AFAICT. Surely the proxy or the server MAY
> report an error but they are not required to. More generally, there is
> currently no requirement for the server to report syntax errors that do not
> affect its processing of the message. For example, if the request included a
> malformed Content-Location header, then the server wouldn't have to report
> an error if it ignores Content-Location. Content-Length is a special case
> because of its wide-ranging effects on parsing, but even for it there isn't
> any such requirement. See issue 95 [1] and issue 93 [2].
> 
> [1] http://tools.ietf.org/wg/httpbis/trac/ticket/95
> [2] http://tools.ietf.org/wg/httpbis/trac/ticket/93

Good points.  A most lenient server/client could choose the smaller of the
numbers, and assume connection: close as it doesn't know where to begin
(the contradiction inhibits the ability to determine valid keep alive/next
request point).  This is similar to the presence of both content length and
content encoding of chunked.

But error handling is left to the client.  The condition is an error,
so you are correct when you say the spec has nothing to say about the 
contradiction.  I wonder if your notes on 95 are better left to commentary
under Security Considerations?

Received on Thursday, 28 August 2008 19:16:28 UTC