Re: NEW ISSUE: repeating non-list-type-headers

Hi.

It seems to me that we really should open a separate issue (*) for this 
one, so that it doesn't get lost.

BR, Julian

(*) As compared to: <http://tools.ietf.org/wg/httpbis/trac/ticket/93>.


Jamie Lokier wrote:
> Bjoern Hoehrmann wrote:
>> * Jamie Lokier wrote:
>>>>    Multiple message-header fields with the same field-name MUST NOT be
>>>>    present in a message unless the entire field-value for that
>>>>    header field is defined as a comma-separated list [i.e., #(values)].
>>> It would be clearer, but it would clash with reality.  All web servers
>>> and web clients use Set-Cookie, which is prohibited by that.
>> I re-read RFC 2109 and it seems you are mistaken, Set-Cookie as defined
>> there takes a comma-separated list.
> 
> RFC2109 is not implemented by anybody as far as I know.
> 
> Firstly, cookie _values_ in Set-Cookie may contain a comma which
> _mustn't_ be quoted because quotes are considered part of the value.
> When a value is unquoted, RFC2109 says it must match token syntax, but
> even today that's not conformed to.  And RFC2109 doesn't describe an
> "expires=" attribute, but of course nearly all cookies have one, and
> they don't have the "max-age=" attribute with RFC2109 recommands.
> Finally, as you note, unquoted comma in expires attributes - in fact
> quoting is not allowed historically for that either.
> 
> See how many RFC2109 non-compliances you can find in this header I got
> today from Google, for example.
> 
>   Set-Cookie: PREF=ID=823cb075fecf6437:TM=1195776675:LM=1195776675:S=WADqk8jBntt5y3gk; expires=Sun, 22-Nov-2009 00:11:15
> 
> (That nobody implements RFC2109 is implied in RFC2965, which obsoletes
> RFC2109 and in section 9 talks about using Set-Cookie2 alongside
> Netscape style Set-Cookies, not mentioning RFC2109 style Set-Cookiess.
> I think this reflects the observation at the time that the change of
> Set-Cookie syntax promoted in RFC2109 wasn't taken up, probably
> because it's not backward compatible.)
> 
>> There are a number of problems with commas in cookies, like unquoted
>> expires parameters and clients that can't parse the header properly,
> 
> Clients which parse the header according to RFC2109 are going to break
> quickly in the wild.  But worse: servers which send headers according
> to RFC2109 are going to break quickly in the wild too; there's no
> transition mechanism to clean it up, except Set-Cookie2, which hasn't
> taken off in a big way, although it might do so eventually.
> 
>> but this part of the specification is unlikely the right place to
>> highlight them. Am I missing something?
> 
> I think this is exactly the right place to highlight that generic HTTP
> message parsers need to handle Set-Cookie specially if they apply
> header folding in the common internet.  E.g. proxies have to get this
> right (which is why I proposed text which tells them to), as do
> generic HTTP processing modules that pass headers along on behalf of
> applications, in both servers and clients.
> 
> Where else would this logically go?  This is _the_ only standard text
> about how to parse multiple HTTP headers and fold duplicates.
> 
> It is such a common requirement to get this right in _generic_ HTTP
> header handling code, not code which handles cookies, and it's not
> going away.  Thus, imho, it's relevant to a HTTP specification, even
> if it has to go in the equivalent of RFC 2616 "19.3 Tolerant
> Applications"... except this isn't about tolerance.
> 
> It's not even anyone's implementation bug.  It was simply specified
> that way by Netscape, and everyone who uses cookies still uses that
> specification.
> 
> -- JAmie
>

Received on Monday, 16 June 2008 11:21:26 UTC