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

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 Friday, 23 November 2007 00:38:48 UTC