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

From: Julian Reschke <[email-masked]>
Date: Tue, 20 Nov 2007 10:46:40 +0100

Hi,

(follow-up to a discussion over at the HTML mailing list, see 
<http://lists.w3.org/Archives/Public/public-html/2007Nov/0271.html>).

We currently say in Section 4.2:

    Multiple message-header fields with the same field-name MAY be
    present in a message if and only if the entire field-value for that
    header field is defined as a comma-separated list [i.e., #(values)].

-- <http://tools.ietf.org/html/rfc2616#section-4.2>

Now this seems to be kind of backwards, wouldn't it be *much* clearer if 
it said:

    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)].

That being said, do we have a recommendation for recipients when that 
requirement is violated? I would assume that servers SHOULD return a 400 
(Bad Request), but what about clients?

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 20 Nov 2007 11:01:04 +0100

>    header field is defined as a comma-separated list [i.e., #(values)].

No, unlike the old text, that does not say when you may use them.

>(Bad Request), but what about clients?

You fold them into a single value as the specification suggests unless
there is some reason not to do that. Servers should not be required to
respond with Bad Request, they might not know the header, and they
should not treat

  X: a
  X: b

differently from X:a,b, so if they don't give you a Bad Request for the
latter, they should not do it for the former. I think the current text
is fine.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Tue, 20 Nov 2007 11:09:08 +0100

> No, unlike the old text, that does not say when you may use them.

Ahem? "...unless the entire field-value..."?

> there is some reason not to do that. Servers should not be required to

Well, for Content-Type the specification says you can't do that.

> latter, they should not do it for the former. I think the current text

Of course both forms should be treated the same. The question I was 
asking: what is a recipient -- in particular a client -- supposed to do 
with a message where header values are known to be invalid?

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 20 Nov 2007 11:59:14 +0100

>Ahem? "...unless the entire field-value..."?

You are turning "Messages may X iff Y" into "Messages must not X unless
Y"; if Y is true, with the old version you know "Messages may X", with
your version you just know you are not violating "Messages must not X".
It might well be that Messages SHOULD NOT include duplicates even then.

>with a message where header values are known to be invalid?

Where the specification does not say that, the client is supposed to do
something that's appropriate for the particular client and the circum-
stances it is acting in. Some clients may close the connection on sight
of the bad header, others might ignore it, others might process only
some part of it, and yet others might not notice the error at all. It's
unlikely there is a one size fits all recommendation we could make.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Tue, 20 Nov 2007 12:09:01 +0100

> It might well be that Messages SHOULD NOT include duplicates even then.

Sorry?

Unless there's another place in the spec making statements about 
repeating headers (is there?), both

   MAY do X, iff Y

and

   MUST NOT do X, unless Y

are equivalent.

> unlikely there is a one size fits all recommendation we could make.

I'm concerned about clients that ignore the problem and randomly pick 
one of the values.

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 20 Nov 2007 12:18:24 +0100

>repeating headers (is there?), both

Well you see, with your text you would have to search the rest of the
specification to be sure, while that is not necessary with the old text.
Your goal was to make the text clearer and less backwards, I think you
did the opposite.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 20 Nov 2007 12:17:36 +0100

Bjoern Hoehrmann wrote:

> You are turning "Messages may X iff Y" into "Messages must not X unless Y"

You've lost me here, isn't that logically equivalent ?  If it is equivalent
Julian's version is clearer.  If it is not I likely miss the point.

 Frank

---

From: Adrien de Croy <[email-masked]>
Date: Wed, 21 Nov 2007 00:29:33 +1300

> repeating headers (is there?), both
neither of these constructs are that great - having read this one being 
thrashed out in other conversations.  I think we need to look into what 
the goal is.  Clarity surely?

there are complications as previously discussed around use of the word 
"MAY", in the strict (RFC defined) sense, vs the everyday sense

Personally I feel the first form is more correct, since to derive the 
same meaning from the second form, you have to implicitly convert a 
conditional non-denial into an optional conditional permission.  They 
aren't 100% the same thing. Lack of denial is not necessarily a grant of 
permission.  There may be other factors.

If you want real clarity, we may need to say something more convoluted, 
i.e. repetitive, such as

MAY do X but only if Y. If not Y then MUST NOT do X

It's redundant etc, but it drums in that doing X is _optional_, but only 
on condition that Y is met, otherwise X is not permitted.

Use of the word "only" (which is in the spec in a few places) can make 
things a bit fuzzy.  Adding "but" can help there in terms of general 
legibility.

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

---

From: Julian Reschke <[email-masked]>
Date: Tue, 20 Nov 2007 13:08:06 +0100

Adrien de Croy wrote:
> ...

Agreed. None of the header types (list and others) is an exception, so 
it probably makes sense to spell out both explicitly.

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 20 Nov 2007 12:49:57 +0100

>Julian's version is clearer.  If it is not I likely miss the point.

Julian's version allows using the same name more than once through a
double negative under the assumption that MAY is the antonym of MUST
NOT. I would not make this assumption, and I think double negatives
are generally more difficult to understand than positive statements.

If you want clearer text you would have to split the statements up
and say: list-valued headers may occur more than once, other headers
must not occur more than once.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Tue, 20 Nov 2007 13:36:44 +0100

> are generally more difficult to understand than positive statements.

No, "MUST NOT" is not an antonym for "MAY".

However

	MAY do X if and only if Y

means the same as

	MUST NOT do X unless Y

I think the latter was clearer as it communicates that the default is 
that repeating header names are not allowed (that is, headers using list 
syntax being the exception).

> must not occur more than once.

Agreed.

BR, Julian

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 20 Nov 2007 13:55:04 +0100

> must not occur more than once.

Okay, something in this direction will do.  Maybe twist that "may" 
into a "should not" if it's known to cause trouble.  

 Frank

---

From: Julian Reschke <[email-masked]>
Date: Tue, 20 Nov 2007 14:15:35 +0100

> into a "should not" if it's known to cause trouble.  

No, the "may" is perfectly fine in case the header uses the list syntax...

BR, Julian

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 20 Nov 2007 14:56:54 +0100

Julian Reschke wrote:
 
> the "may" is perfectly fine in case the header uses the list syntax...

A bit unusual, but if it works as expected, good.  I vividly recall
an excursion into the weeds with multiple a=b ; a=c name=value pairs
instead of a="b c" elsewhere, once bitten twice shy... ;-)

---

From: Jamie Lokier <[email-masked]>
Date: Tue, 20 Nov 2007 16:00:53 +0000

>    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 think it's important to acknowledge that Set-Cookie is still around,
and all public web servers and clients must deal with it in practice
(if they support cookies).

> (Bad Request), but what about clients?

An HTTP agent's implementation _ought_ to be able to parse the headers
into a name->value dictionary, concatenating any multiple values for
the same field-name with ", " between them, with the practical
exception of Set-Cookie, for which a list must be kept separately.

Some servers and clients are implemented like that, and they are fine.

The module responsible for parsing headers generally doesn't have a
list of the syntaxes of each header type, and such a list would be
difficult to obtain because of application-specific headers which may
be different for different resources on the same server.

Hence the open-endedness of the text you focused on in RFC 2616, I guess.

-- JAmie

---

From: Julian Reschke <[email-masked]>
Date: Tue, 20 Nov 2007 17:16:13 +0100

> and web clients use Set-Cookie, which is prohibited by that.

Well, it clashes with reality the same way the old text did :-)

That being said, we should treat that as separate issue. I believe Roy 
mentioned that problem before.

Agreed.

> Hence the open-endedness of the text you focused on in RFC 2616, I guess.

That's all true, but it doesn't answer the question of what a recipient 
should do with something like:

    Content-Type: text/html; charset=ISO-8859-1
    Content-Type: text/plain

(see <http://lists.w3.org/Archives/Public/public-html/2007Nov/0271.html>).

...or even worse, with conflicting Content-Length headers....

Best regards, Julian

---

From: David Morris <[email-masked]>
Date: Tue, 20 Nov 2007 08:53:22 -0800 (PST)

> ...or even worse, with conflicting Content-Length headers....

In the end, quite simple ... if the recipient doesn't understand the
message, it should report an error and reject the message. As I recall,
in the original 1.1 time frame, there was a discussion of creating a
mechanism where by user agents could report errors to origin servers and
this was rejected, in part at least, because of concerns re. DOS attacks.

There really isn't that much point in folding headers and in fact this
possiblity makes parsing more difficult. What a revised spec should do is
focus on interoperability and describe requirements which insure
interoperability...

a. The order of the values of repeated header must be preserved
b. The order of repeated headers known to have list values MAY be
   folded OR unfolded at the convenience of the processing entity.
c. The Content-type example is no more confusing than receiving a
   flash movie (.flv type) coded as text/plain. Processing entities
   must write code which will survive the wild west. The most we should
   do is list alternatives and recommend that any individual
   implementation be consistent. Take the first, take the last, use as
   hints in analysis of the actual entity... Report as an error.

Where it doesn't matter, the specification should not impose restrictions
since there is no power of enforcement.

Dave Morris

---

From: Jamie Lokier <[email-masked]>
Date: Tue, 20 Nov 2007 21:18:19 +0000

> and web clients use Set-Cookie, which is prohibited by that.

After reading the rest of this thread, I see that you didn't
change the meaning (I was mistaken), you simply clarified it,
(notwithstanding the subtleties of double negatives and permission
vs. not-denial etc.).  So I withdraw any objection on that basis.

However, I still have a point which is mainly response to your other
query, and I offer an alternative clarification which spells it out
more.

> > (Bad Request), but what about clients?

Recipients don't always have the necessary information to decide which
headers have comma-separated syntax.  Some headers meaning may depend
on which resource is requested and other factors, outside the scope of
the general purpose HTTP part of an implementation.

Only recipients which _intepret_ a particular header are likely to
have this information for that header.  In that case, perhaps it's
reasonable to say _those_ SHOULD return 400 Bad Request.

However, I think that's a bit demanding.  There are quite a few client
and server implementations which parse HTTP headers into a key->value
dictionary at an early stage, folding duplicates together, and pass
that onto application code, and only application code has knowledge of
the meaning of some headers.  It works fine even on the big nasty
internet.  (Set-Cookie is handled separately).

That architecture seems reasonable to me, so I propose replacing
SHOULD with MAY, as in "... MAY return a 400 (Bad Request)".

Dave Morris wrote:
> message, it should report an error and reject the message.  [...]

I agree, and add that aspects of the message which the recipient
doesn't care about should stay ignored.

> possiblity makes parsing more difficult.

But it's required now, it really occurs in the wild with some headers.

> What a revised spec should do is

I agree, and think the old spec is a bit weak in some
found-in-practice interop areas.

> a. The order of the values of repeated header must be preserved

Yes.

>    folded OR unfolded at the convenience of the processing entity.

True when interpreting headers, but please don't write a proxy which
forwards those folded/unfolded headers - especially not a
"transparent" proxy.  A few buggy clients/servers do process the two
differently, and occasionally one needs to be explicit as a workaround
for some problem, and proxies "normalising" things does not help.

> since there is no power of enforcement.

I echo that, when it comes to things like what to do when sent some
kinds of technically malformed message.  However, restrictions which
say what to send (and what not) are good for interoperability, as are
requirements that insist everyone parse different but equivalent
things the same way.

How about this.  It's a bit long, but I think it's clear, reflects
common practice as well as suggesting good practice, includes Julian's
suggestion to reject (but only when appropriate), and is equivalent to
Daves suggestion "folded or unfolded at the convenience" without
putting it that way.

Proposed text:

Duplicate headers
=================

1. Duplicate headers means duplicate headers with the same
   field-name.  Case differences and LWS before the colon MUST be
   ignored in the comparison.

2. Messages MUST NOT have duplicate headers, except as permitted:

      + Headers whose field-value syntax is a comma-separated list.

      + More generally, when explicitly permitted by other
        specifications and applications, whose syntax is such that
        concatenating syntactically valid values with "," (with and
        without surrounding LWS) does not change the interpretation.

      + Headers received and forwarded unmodified by a proxy (except
        leading and trailing LWS and multi-line formatting changes,
        and field-name case changes).

      + Set-Cookie in a response message, due to historical accident.

3. An implementation SHOULD NOT reject a message for containing
   duplicate headers unknown to the implementation.

4. At the point where specific headers are interpreted during message
   processing, if duplicates are present and not permitted as
   described above, the message SHOULD be rejected as malformed.

5. An implementation MAY reject the message earlier using a list of
   headers for which duplicates are not permitted (e.g., at least
   those defined in this specification whose syntax is not a
   comma-separated list).

6. The meaning of duplicate headers whose field-value syntax is a
   comma-separated list, provided the individual values satisfy that
   syntax, is equivalent to concatening the elements of each list,
   preserving the order.  The transformation of section 7 gives the
   same result.  Implementations MUST respect this equivalence.

7. When interpreting any header, implementations MAY merge duplicates
   by concatenating the values with "," between them (optionally with
   LWS), preserving the order.  This is permitted for all headers and
   independent of syntax.  In practice, some implementations do merge
   all duplicate headers in this way internally, except for
   Set-Cookie, and the technique does satisfy this specification.
   However, see sections 4 and 5 for preferred behaviours.

8. When a proxy forwards particular headers without modification
   (except leading and trailing LWS and multi-line formatting changes,
   and field-name case changes), duplicate headers MUST be forwarded
   separately in their original order.  A proxy may still apply
   sections 4, 5, 6 and 7 separately to header interpretation, and it
   may replace duplicate headers with the concatenated form for those
   headers whose value is modified prior to forwarding.

-- Jamie

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 20 Nov 2007 22:54:12 +0100

> ...or even worse, with conflicting Content-Length headers....

Reject it, ignore the header, or try to make the best out of it. It's up
to the implementer omho. Implementation detail on how to behave when
seeing things outside specifications. My preferred action when seeing
things violating a MUST NOT is to reject the message as invalid unless
specs says otherwise, but current specs sometimes promote ignoring
instead.. (i.e. Content-Length together with chunked encoding). Very
many implementations picks one (first or last) of the available
alternatives.

For security reasons Content-Length requires special attention as it
also transport related, and there the sane thing is to reject the
message, or if that's not possible for whatever reason then use the
biggest one or act as if Content-Length was not given..

I don't really see it as a problem except for content-length.

Regards
Henrik

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 21 Nov 2007 15:14:36 +0100

>Proposed text:

I largely disagree with the proposal, the existing text is quite clear

>Duplicate headers

The specification already says that field-names are case-insensitive,
and white space cannot be part of the field-name (I don't think the
grammar was meant to allow white space preceding the colon either).

>        and field-name case changes).

I am not sure why you have the latter two items, they seem to extend
when duplicates are allowed, which they should not.

>      + Set-Cookie in a response message, due to historical accident.

It's not clear to me that this needs to be allowed, and if so, it's
unclear to me that this is the only case that needs to be allowed.

>   duplicate headers unknown to the implementation.

Why is it necessary to say this?

>   described above, the message SHOULD be rejected as malformed.

I disagree with this, for example, Apache will reject requests with
multiple Content-Length headers with Request Entity Too Large, not
Bad Request; further, there is no reason that I can see why servers
should handle "X: a\nX: b" differently from "X: a,b" if neither is
allowed.

>   those defined in this specification whose syntax is not a

They already may "reject" them as they see fit, I see no need to re-
peat this here.

>   same result.  Implementations MUST respect this equivalence.

I am not sure what this is trying to say, but it's a lot less clear
than the existing text, especially on which order they should occur
in the combined value.

>   However, see sections 4 and 5 for preferred behaviours.

This is already implicit.

>   headers whose value is modified prior to forwarding.

This does not make sense (if proxy does not modify, then proxy must
not modify); again I do not see what this adds over the existing text.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Wed, 21 Nov 2007 15:23:58 +0100

> when duplicates are allowed, which they should not.

Correct.

> unclear to me that this is the only case that needs to be allowed.

It's unfortunate, but I think it would be a service to readers of the 
spec to make them aware of that exception.

> multiple Content-Length headers with Request Entity Too Large, not

I would consider that a bug; why would you say that the request entity 
is too large if you don't know how large it is?

> should handle "X: a\nX: b" differently from "X: a,b" if neither is

Correct.

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 21 Nov 2007 15:40:40 +0100

>spec to make them aware of that exception.

I would not mind a note and certainly expect the State Management part
to point this issue out, but allowing this practise is a different issue
(that should be discussed in some other thread anyway).

>is too large if you don't know how large it is?

Because that's what you get if the header is malformed in some other
way and because it requires less logic in the server's code. This may
not be ideal, but I can see no reason to outlaw this either.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Geoffrey Sneddon <[email-masked]>
Date: Wed, 21 Nov 2007 16:10:45 +0000

On 20 Nov 2007, at 21:54, Henrik Nordstrom wrote:

> It's up to the implementer omho. Implementation detail on how to  
> behave when
> seeing things outside specifications.

I strongly disagree — as an implementer, I want to be able to  
implement HTTP in such a way that it works in the real world (which,  
in places, relies on totally unspecified behaviour found in browsers)  
by just reading the spec. If RFC2616bis doesn't address this, other  
documentation on this will likely appear scattered over the web  
outwith the HTTP spec. If I cannot just implement HTTP from the spec  
in such a way that is interoperable with real-world servers, then IMHO  
the spec is too vague and I have to waste my time reverse-engineering  
other implementations (likely still not in a way 100% interoperable  
with real-world servers).

--
Geoffrey Sneddon
<http://gsnedders.com/>

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 21 Nov 2007 17:36:06 +0000

> (that should be discussed in some other thread anyway).

How can you not "allow" it?

_Every_ HTTP implementation dealing with the web in any significant
way must implement it, even those which handle Set-Cookie2 as well, so
it's silly to make it a MUST NOT condition in the spec.

> not be ideal, but I can see no reason to outlaw this either.

In my proposal it's not outlawed.  It SHOULD reject the message as
malformed, which makes sense; it's not a MUST.

Really, Apache should have a function which means "get me the value of
header X and if it's duplicated, return an error code", generically,
and use that for all headers where it makes sense.

-- Jamie

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 21 Nov 2007 17:32:04 +0100

* Geoffrey Sneddon wrote:
>> behave when seeing things outside specifications.
>

There is no contradiction. You can leave this up to implementers and
point out real-world problems and how they might be addressed at the
same time. Further, while you might want suggestions for implementing
a "web browser", others might want suggestions for implementing some
web service client, and there may well be differences. Documentation
on such real world problems would be very welcome, you can easily put
them into a separate draft and publish it alongside the Working Group's
documents.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 21 Nov 2007 17:39:31 +0100

>it's silly to make it a MUST NOT condition in the spec.

If you think so, the best course of action would be to open a new issue
specifically on Set-Cookie. I would disagree with your logic though, we
also don't allow, say, sending a body in HEAD responses even though that
too is something many implementations have to cope with.

>malformed, which makes sense; it's not a MUST.

Recommendations one way or another are already implied in the semantics
of status codes and generic good behavior recommendations and common
sense; a "SHOULD" goes considerably beyond that, and I would not say the
reasons I gave are good enough to violate such a "SHOULD".
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Henrik Nordstrom <[email-masked]>
Date: Wed, 21 Nov 2007 23:44:10 +0100

> with real-world servers).

The specs do not always say what you must do when someone sends you
stuff which doesn't make sense or which isn't allowed to be sent. I
don't think it should. It's best left to each implementer how much crap
they accept as valid, or how/if they inform the user that there is crap
given to them on the wire.

Specs do say what is allowed, and how that is to be understood. Any
glitches there is what RFC2616bis aims at correcting, plus increasing
the overall readability of what is said.

It's only worth considering crap when it has serious implications on
security-

Regards
Henrik

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 22 Nov 2007 20:57:46 +0100

>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. There are a number of problems with
commas in cookies, like unquoted expires parameters and clients that
can't parse the header properly, but this part of the specification is
unlikely the right place to highlight them. Am I missing something?
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Jamie Lokier <[email-masked]>
Date: Fri, 23 Nov 2007 00:38:31 +0000

Bjoern Hoehrmann wrote:
> 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

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 27 Nov 2007 21:21:58 -0800

Now i93; <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i93>.

On 20/11/2007, at 1:46 AM, Julian Reschke wrote:

> Now this seems to be kind of backwards, wouldn't it be *much*  
> clearer if it said:
>
> That being said, do we have a recommendation for recipients when  
> that requirement is violated? I would assume that servers SHOULD  
> return a 400 (Bad Request), but what about clients?
>
> Best regards, Julian
>

--
Mark Nottingham     http://www.mnot.net/