Subject: Re: [http-state] Is this an omission in the parser rules of draft-ietf-httpstate-cookie-21?

From: "Remy Lebeau" <[email-masked]>
Date: Fri, 04 Feb 2011 11:47:35 -0700

-------- Original Message --------
Subject: Re: [http-state] Is this an omission in the parser rules of
draft-ietf-httpstate-cookie-21?
From: Adam Barth <[email-masked]>
Date: Fri, February 04, 2011 10:19 am
To: Remy Lebeau <[email-masked]>
Cc: [email-masked]

> The draft gives user agents precise 
> instructions for how to parse all
> manner of cookies, including cookies with
> values that contain quote characters.  That 
> information is contained in Section 5

I have re-read Section 5 and I do not see its grammar or parsing rules
accounting for quoted-string values at all. It only says to remove WSP
characters surrounding extracted names and values, and quote characters
are not part of the WSP definition. So what am I missing? Where exactly
does it say how to unquote a quoted-string used in attribute values?

---

From: Adam Barth <[email-masked]>
Date: Fri, 4 Feb 2011 10:51:16 -0800

On Fri, Feb 4, 2011 at 10:47 AM, Remy Lebeau <[email-masked]> wrote:
> From: Adam Barth
> To: Remy Lebeau

Precisely.  It does not say to unquote a quoted-string because that's
not how cookies work.  The role of the quote character is cookies is
identical to the role of the "!" character.  That is, neither play a
special role in the protocol.  Any representations by the contrary by
2109 or any other document are fiction and have only caused pain and
misery in the world.

Adam

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 4 Feb 2011 11:24:38 -0800

> 2109 or any other document are fiction and have only caused pain and

That may be, but the grammar for server generation of set-cookie
values is clearly wrong because use of DQUOTE in cookie values is
common (roughly 10% of the values in my browser cookie store) and
previously defined, even if we consider DQUOTE to be part of the
value string.  Let's just change the generating grammar for value to
match how cookies are actually parsed and only exclude characters
that are known to cause failures.

....Roy

---

From: Adam Barth <[email-masked]>
Date: Fri, 4 Feb 2011 11:29:17 -0800

> that are known to cause failures.

The grammar is not used for parsing.  Parsing is defined in Section 5,
not Section 4.

Adam

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 10 Feb 2011 17:59:21 -0700

> The grammar is not used for parsing.  Parsing is defined in Section 5,

Right. And I think the revised text in version -21 (with revisions to
address the IESG comment from Robert Sparks) makes that fairly clear.

Adam, did you propose specific text addressing Dan Winship's original
issue about "cookie-value=token"? As far as I can see, that's the only
substantive issue raised in this thread, but I admit that I might have
missed something.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Adam Barth <[email-masked]>
Date: Thu, 10 Feb 2011 17:09:02 -0800

> substantive issue raised in this thread, but I admit that I might have

Sure:

diff --git a/drafts/cookie.xml b/drafts/cookie.xml
index e0a53f3..17cc0a5 100644
--- a/drafts/cookie.xml
+++ b/drafts/cookie.xml
@@ -335,7 +335,8 @@ set-cookie-header = "Set-Cookie:" SP set-cookie-string
 set-cookie-string = cookie-pair *( ";" SP cookie-av )
 cookie-pair       = cookie-name "=" cookie-value
 cookie-name       = token
-cookie-value      = token / ""
+cookie-value      = token / *base64-character
+base64-character  = ALPHA / DIGIT / "+" / "/" / "="
 token             = <token, defined in [RFC2616], Section 2.2>

 cookie-av         = expires-av / max-age-av / domain-av /
@@ -370,7 +371,7 @@ extension-av      = <any CHAR except CTLs or ";">

           <t>To maximize compatibility with user agents, servers that wish to
           store arbitrary data in a cookie-value SHOULD encode that data, for
-          example, using Base 16 <xref target="RFC4648" />.</t>
+          example, using Base64 <xref target="RFC4648" />.</t>

           <t>The portions of the set-cookie-string produced by the cookie-av
           term are known as attributes.  To maximize compatibility with user

Adam

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 14 Feb 2011 16:41:23 -0700

>            term are known as attributes.  To maximize compatibility with user

WFM, and that seems to capture list discussion.

Adam, I'll follow up with the remaining IESG members this week and
perhaps ask you to submit a revised I-D so we can finish this off. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Adam Barth <[email-masked]>
Date: Mon, 14 Feb 2011 15:43:04 -0800

> perhaps ask you to submit a revised I-D so we can finish this off. :)

Yay!

Adam

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 14 Feb 2011 19:23:26 -0800

> The grammar is not used for parsing.  Parsing is defined in Section 5,

Parsing for user agents is defined in section 5.  Servers have to
parse cookies as well, and the grammar provided in section 4 is wrong
for both generation and parsing.

Why do you want to push forward a document with a known error in the
grammar?  Just fix it.

This is not a trivial detail.  As written, the specification says
server developers SHOULD break sites like amazon.com.

   cookie-value      = token / ""

The correct grammar is in the original Netscape cookie spec: "This
string is a sequence of characters excluding semi-colon, comma and
white space."  Which easily translates (conservatively) into

   cookie-value      = %x21-2B / %x2D-3A / %x3C-7E / %x80-FF

and it does not conflict with section 5.

....Roy

---

From: Adam Barth <[email-masked]>
Date: Mon, 14 Feb 2011 20:42:13 -0800

> for both generation and parsing.

I agree that the grammar depicted in Section 4 is not appropriate for
parsing.  That grammar is not for parsing.  It's for generation.
Perhaps we should add instructions for how servers should parse the
Cookie header?  That's absent from the current document.

As for generation, there's no exogenous notion of correctness.  We can
speak about usefulness, if you like, but correctness is endogenous to
this document.

> Why do you want to push forward a document with a known error in the

I disagree that it's an "error."

>   cookie-value      = token / ""

Can you explain how the developers of site B using a restricted
grammar for generation will break amazon.com?  That seems entirely
non-sensical.

> and it does not conflict with section 5.

I've updated the draft to recommend the grammar below for generating
cookie-values:

cookie-value      = token / *base64-character
base64-character  = ALPHA / DIGIT / "+" / "/" / "="

Do you have a particular use case in mind for generating Set-Cookie
headers outside this grammar?

Adam

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 15 Feb 2011 12:29:23 -0800

> Cookie header?  That's absent from the current document.

We don't need more instructions.  We need a correct ABNF that tells
us what to generate and what to parse.

> speak about usefulness, if you like, but correctness is endogenous to

Then you should delete the introduction, since it says

   This document specifies the syntax and semantics of these headers as
   they are actually used on the Internet.  In particular, this document
   does not create new syntax or semantics beyond those in use today.

> I disagree that it's an "error."

Then please explain to Amazon why you want to break their site?
Look at your browser's cookies for amazon.com and you will probably
find cookies named session-token, at-main, and x-main that do not
follow your grammar.  They are quoted strings and valid under all
prior descriptions of the Cookie and Set-Cookie header fields.

And while you are at it, maybe you'd like to explain to Google
why you want to make Google Analytics cookies invalid.

http://code.google.com/apis/analytics/docs/concepts/gaConceptsCookies.html

The cookie named __utmz is not a quoted-string, not a token, and not base64.

> grammar for generation will break amazon.com?  That seems entirely

Site B is Amazon.com.  You are editing a proposed standard for the
Internet and, last I checked, they use HTTP on the Internet.

> headers outside this grammar?

Yes.  Backwards compliance with existing content stored within
several hundred million deployed browsers that won't expire
until sometime in 2031 dictates that the grammar be

because servers have to parse Cookie in every form that they
ever sent a Set-Cookie in the past.

Why are you arguing against this?  You are adamant about
supporting the above syntax in browsers, for the same reasons,
and there is no harm in supporting the complete Netscape syntax
in the server grammar.

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Tue, 15 Feb 2011 21:45:15 +0100

On 15.02.2011 21:29, Roy T. Fielding wrote:
> ...
> ...

Indeed.

If this spec wants to describe cookies-as-used, there's little reason to 
disallow certain cookies when they do interop today, and are not harmful 
with respect to security.

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Tue, 15 Feb 2011 13:11:15 -0800

> ever sent a Set-Cookie in the past.

You really think we should recommend that servers use invalid UTF-8
sequences as cookie-values?  That sounds like bad advice...

Adam

---

From: Julian Reschke <[email-masked]>
Date: Tue, 15 Feb 2011 22:22:28 +0100

> sequences as cookie-values?  That sounds like bad advice...

Could you elaborate? Is there client code out there that assumes cookie 
values to *be* UTF-8?

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Tue, 15 Feb 2011 14:05:01 -0800

> Could you elaborate? Is there client code out there that assumes cookie

Regardless of what client code exist, surely servers are better off
avoiding non-ASCII characters in their cookie values.  Using non-ASCII
characters in HTTP headers is just asking for trouble.

Adam

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 15 Feb 2011 15:55:54 -0800

>>> sequences as cookie-values?  That sounds like bad advice...

I am not recommending that they use invalid UTF-8 sequences.
The ABNF only tells the implementer what octets can be used
and what needs to be anticipated while parsing.  If I were
designing a new Cookie protocol, I would exclude the high bits,
but this is how the current Cookie protocol actually works in
practice.

> characters in HTTP headers is just asking for trouble.

It is irrelevant.  HTTP/1.x defined them as ISO-8859-1 and nothing
breaks by treating them as such.  This spec (and the Netscape spec)
defines them as an opaque array of data bytes and nothing breaks
by treating them as such.

I don't know of any implementation that would expect them to be
UTF-8.  I do know that attempting to use a UTF-8 string parser to
parse an HTTP data stream is a known security hole, so there is
no point in worrying about breaking those parsers any further
than they would already be broken (if any still exist -- J2SE
fixed their holes last year).

I don't have any objection to a sentence that says servers
SHOULD NOT send %x80-FF even though the grammar allows it.
But I don't see any need for it either given the apparent
interoperability shown by user agents.

....Roy

---

From: Adam Barth <[email-masked]>
Date: Tue, 15 Feb 2011 17:46:02 -0800

> but this is how the current Cookie protocol actually works in

I feel like I'm just repeating myself.  The text you're complaining
about does not define how to parse a Set-Cookie header.

> interoperability shown by user agents.

That's essentially what the current document says.  The only
difference is that it also recommends that servers not generate
characters such as %x24, whose role in cookies has been muddied by RFC
2965.

Adam

---

From: Adam Barth <[email-masked]>
Date: Tue, 15 Feb 2011 17:51:24 -0800

> about does not define how to parse a Set-Cookie header.

To be crystal clear, this is the only text in the document that refers
to this figure:

          Servers SHOULD NOT send Set-Cookie headers
          that fail to conform to the following grammar:

Adam

---

From: "Remy Lebeau" <[email-masked]>
Date: Tue, 15 Feb 2011 23:04:28 -0800

----- Original Message ----- 
From: "Roy T. Fielding" <[email-masked]>
To: "Adam Barth" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, February 15, 2011 12:29 PM
Subject: Re: [http-state] Is this an omission in the parser rules 
ofdraft-ietf-httpstate-cookie-21?

> prior descriptions of the Cookie and Set-Cookie header fields.

While we are on the subject of breaking Amazon cookies, here is a cookie I 
received from Amazon's homepage that does not conform to the format of the 
Expires attribute that Section 4 requires servers to use, but it is a 
perfectly valid cookie:

    Set-Cookie: bpx_ustats="iGfxfWHBtMzz9EqcZRPVxHOwPlefXNwx/nZTGCcg9tU="; 
Version=1; Max-Age=86400; Expires=Thu, 17-Feb-2011 06:09:08 GMT; Path=/

Here is the Section 4 grammar:

    expires-av        = "Expires=" sane-cookie-date
    sane-cookie-date  = <rfc1123-date, defined in [RFC2616], Section 3.3.1>

>From RFC 2616:

    rfc1123-date = wkday "," SP date1 SP time SP "GMT"
    wkday        = "Mon" | "Tue" | "Wed"
                        | "Thu" | "Fri" | "Sat" | "Sun"
    date1        = 2DIGIT SP month SP 4DIGIT
    time         = 2DIGIT ":" 2DIGIT ":" 2DIGIT

Notice that the cookie is not using the "date1" grammar.

Since the cookie has a Version=1 attribute, it is an RFC 2109 cookie, and 
RFC 2109 allows Netscape-style date/time formatting:

    Wdy, DD-Mon-YYYY HH:MM:SS GMT

The cookie is conforming to that, but the draft does not allow servers to 
use that format anymore (but user agents can parse it, per Section 5).

---

From: Dan Winship <[email-masked]>
Date: Wed, 16 Feb 2011 08:30:02 -0500

On 02/16/2011 02:04 AM, Remy Lebeau wrote:
> Since the cookie has a Version=1 attribute, it is an RFC 2109 cookie,
> and RFC 2109 allows Netscape-style date/time formatting:
> 

Not that any of this is in any way relevant, but, no it doesn't. RFC
2109 doesn't allow the Expires attribute at all. A cookie that contains
both "Version=1" and "Expires=..." does not conform to *any* spec.

-- Dan

---

From: "Remy Lebeau" <[email-masked]>
Date: Thu, 17 Feb 2011 11:45:55 -0800

(Not sure if this got posted correctly, so re-posting)

----- Original Message ----- 
From: "Dan Winship" <[email-masked]>
To: "Remy Lebeau" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, February 16, 2011 5:30 AM
Subject: Re: [http-state] Is this an omission in the parser rules 

> both "Version=1" and "Expires=..." does not conform to *any* spec.

Expires was not in the RFC 2109 grammar for the Set-Cookie header, but most 
implementations did not use Max-Age. The draft allows user agents to support 
both from a server, and RFC 2109 Section 10.1.2 told user agents to 
recognize Expires if present:

10.1.2  Expires and Max-Age

   Netscape's original proposal defined an Expires header that took a date 
value in a fixed-length variant format in place of Max-Age:

   Wdy, DD-Mon-YY HH:MM:SS GMT

   Note that the Expires date format contains embedded spaces, and that 
"old" cookies did not have quotes around values.  Clients that implement to 
this specification should be aware of "old" cookies and Expires.

The wording of that last sentence does not suggest to me, at least, that the 
presence of Expires is strictly dependant on an "old" cookie being used. And 
we can see in real-world cookies that Netscape-style Expires are commonly 
used in RFC-style cookies from servers.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 23 Feb 2011 14:07:44 -0800

>          that fail to conform to the following grammar:

Which, as I said, is an incorrect requirement if this spec is
supposed to reflect how Cookie and Set-Cookie are used on
the Internet.  That should be more obvious in context:

Abstract:

   This document defines the HTTP Cookie and Set-Cookie header fields.
   These header fields can be used by HTTP servers to store state
   (called cookies) at HTTP user agents, letting the servers maintain a
   stateful session over the mostly stateless HTTP protocol.  Although
   cookies have many historical infelicities that degrade their security
   and privacy, the Cookie and Set-Cookie header fields are widely used
   on the Internet.

ToC

   4.  Server Requirements  . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 12
       4.1.1.  Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12
       4.1.2.  Semantics (Non-Normative)  . . . . . . . . . . . . . . 13
     4.2.  Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 16
       4.2.1.  Syntax . . . . . . . . . . . . . . . . . . . . . . . . 16
       4.2.2.  Semantics  . . . . . . . . . . . . . . . . . . . . . . 16
   5.  User Agent Requirements  . . . . . . . . . . . . . . . . . . . 17

4.1.1.  Syntax

   Informally, the Set-Cookie response header contains the header name
   "Set-Cookie" followed by a ":" and a cookie.  Each cookie begins with
   a name-value pair, followed by zero or more attribute-value pairs.
   Servers SHOULD NOT send Set-Cookie headers that fail to conform to
   the following grammar:

set-cookie-header = "Set-Cookie:" SP set-cookie-string

[BTW, the grammar loses indentation because the comment on
max-age-av is too long]

Your argument appears to be that the cookie-value production
doesn't need to reflect actual usage because the specification
does not include a separate section on how servers should parse
received Cookie values.  In other words, the spec is incomplete.

My argument is that server developers (like me) already have
implementations that parse the Cookie value in a similar way
that user agents parse the Set-Cookie value, largely because
those values are set by third-party modules that the server
has no real control over.  BTW, server implementations like
libapreq <http://httpd.apache.org/apreq/> will only allow
embedded whitespace in value if it is a quoted-string.

Therefore, I would like you to change the ABNF so that it
reflects the reality of (Set-)Cookie usage on the Internet,
for the same reason that you have insisted the algorithm
for user agent parsing reflects reality.  Changing the ABNF
to include base64 does not do that -- it is just another
fantasy production that differs from all prior specs of
the cookie algorithm.  Changing it to

or just the minimum

 cookie-value      = %x21-2B / %x2D-3A / %x3C-7E

returns the definition to the original Netscape spec (at
least in the first case), reflects how they are implemented
on the Internet, and eliminates this artificial distinction
between the server and user agent requirements.

>> characters such as %x24, whose role in cookies has been muddied by RFC

I don't see any restrictions on '$' (it is a valid token char).

The current document says

which unnecessarily excludes DQUOTE, "(" , ")" , "<" , ">" ,
"@", ":" , "\" , "[" , "]" , "?" , "{" , and "}".  It excludes
Google's very common __utmz cookie because that cookie's format
uses both pipe "|" (only allowed in token) and equals "="
(only allowed in *base64-character).

I do not see any reason for this working group to invent a
new grammar that has no implementation experience and differs
from every single prior specification of (Set-)Cookies.

The IESG should not approve such an error for publication,
since it will just require us to start this process over.

Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Principal Scientist, Adobe          <http://adobe.com/enterprise>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 23 Feb 2011 15:57:56 -0700

On 2/23/11 3:07 PM, Roy T. Fielding wrote:

<snip/>

>  cookie-value      = %x21-2B / %x2D-3A / %x3C-7E

Hi Roy,

The latter seems fine, and in conversation with Adam he indicated to me
that he would not object to such a change.

However, I see no reason to include characters from the Unicode range
U+0080 to U+00FF in cookie-value. Among other reasons, characters above
U-00A1 would introduce the need for internationalization considerations
of the kind that have derailed many a standardization effort (e.g., in
Unicode U+00BE undergoes compatibility decomposition). Let's avoid that
can of worms if at all possible...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 23 Feb 2011 17:01:51 -0800

> that he would not object to such a change.

Okay by me.

> can of worms if at all possible...

According to the cookie protocol, the value is not characters:
they are just opaque octets.  Generally speaking, i18n considerations
do not apply to opaque OCTETs, though I have no reason to object to such
an exclusion because it is consistent with httpbis recommendation to
avoid the use of %x80-FF in any HTTP header fields.  I do not know
of any use in practice.

....Roy

---

From: Adam Barth <[email-masked]>
Date: Wed, 23 Feb 2011 21:16:25 -0800

>> that he would not object to such a change.

One nit: I would exclude %x22 because there are interoperability
problems with cookie-values that contain %x22.

Adam

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 24 Feb 2011 14:01:12 -0700

> problems with cookie-values that contain %x22.

So:

cookie-value    = %x21 / %x23-2B / %x2D-3A / %x3C-7E

If there are no objections, I'll add an RFC Editor note to that effect.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 24 Feb 2011 13:31:00 -0800

> If there are no objections, I'll add an RFC Editor note to that effect.

There have already been objections -- that is what started this thread.

%x22 is DQUOTE.  I am not aware of any interoperability concerns
with the use of DQUOTE in opaque cookie values, though I can
understand why they might be a concern.  However, use of them as
a quoted-string value (where browsers store the DQUOTEs as more
opaque data) is extremely common because the past two RFCs defined
the value as token / quoted-string.

I just noticed a grammar bug in my suggestion. It should have been

  cookie-value      = *( %x21-2B / %x2D-3A / %x3C-7E )

If we would like to limit the use of DQUOTE to how it was limited
in prior RFCs (matching outer pair), then I suggest

  cookie-value      = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
  cookie-octet      = %x21 / %x23-2B / %x2D-3A / %x3C-7E

since that does cover all current usage that I am aware of and
doesn't allow for odd usages of DQUOTE that might be misinterpreted
by parsers that did not implement the Netscape spec but did
implement one of the RFCs.

....Roy

---

From: "Remy Lebeau" <[email-masked]>
Date: Thu, 24 Feb 2011 21:46:14 +0000

My original problem with DQUOTE handling, and is still a concern for me, is that the current draft does not allow the use of DQUOTE around attribute values at all, let alone around cookie values. DQUOTE around attribute values is common to see because it is part of RFC 2109, and it cannot be treated as opaque data like it can in cookie values. The grammer rules for parsing attributes must allow for recognizing and removing DQUOTE when extracting attribute values.

-----Original Message-----
From: "Roy T. Fielding" <[email-masked]>
Sender: [email-masked]
Date: Thu, 24 Feb 2011 13:31:00 
To: Peter Saint-Andre<[email-masked]>
Cc: http-state<[email-masked]>; <[email-masked]>
Subject: Re: [http-state] parser rules of draft-ietf-httpstate-cookie-22

....Roy

_______________________________________________
http-state mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/http-state

---

From: Adam Barth <[email-masked]>
Date: Thu, 24 Feb 2011 13:50:44 -0800

> implement one of the RFCs.

DQUOTE is a cargo cult.  Matching DQUOTEs, as above, are less
problematic although they do have interoperability problems.  For
example, some user agents will incorrectly parse

Set-Cookie: foo="bar\"; Secure

(allowed by the grammar above) and will not interpret this header as
containing a Secure cookie.  If you insist on DQUOTE, we'll probably
be better off excluding %x5C from cookie-octet.

> My original problem with DQUOTE handling, and is still a concern for me, is that the current draft does not allow the use of DQUOTE around attribute values at all, let alone around cookie values. D…

Based on data about how cookies are used on the Internet and studying
the behavior of existing user agents, we need only tolerate DQUOTE in
the Expires attribute, which the current draft does.  In no case is it
advantageous for a server to send DQUOTE.

Adam

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 24 Feb 2011 14:21:58 -0800

> be better off excluding %x5C from cookie-octet.

Right, that's because the RFCs allowed backslash quoting by referring
to the quoted-string production of HTTP.  Given the choice, I'd rather
lose backslash than DQUOTE.  I haven't seen any Windows pathnames
included in cookie values and sending such data would be unwise.
Excluding %x5C should be okay.

 cookie-value      = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
 cookie-octet      = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
                   ; ASCII characters excluding CTLs, whitespace,
                   ; DQUOTE, comma, semicolon, and backslash

....Roy

---

From: Adam Barth <[email-masked]>
Date: Thu, 24 Feb 2011 14:29:20 -0800

>                   ; DQUOTE, comma, semicolon, and backslash

Works for me.  Thanks Roy.

Adam

---

From: Dan Winship <[email-masked]>
Date: Thu, 24 Feb 2011 17:31:13 -0500

> be better off excluding %x5C from cookie-octet.

I currently have some cookies with \" in them.

Rather than trying to deal with this in the grammar, we could handle it
like Max-Age, and just add "WARNING: If the cookie-value starts with a
DQUOTE, some existing user agents will require it to be a valid
quoted-string."

-- Dan

---

From: Adam Barth <[email-masked]>
Date: Thu, 24 Feb 2011 14:34:25 -0800

> DQUOTE, some existing user agents will require it to be a valid

Those cookies will continue to work fine in user agents that follow
the spec.  However, we shouldn't recommend that servers send those
sorts of cookie values.  They're just causing themselves
interoperability problems.

Adam

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 24 Feb 2011 15:41:36 -0700

> Works for me.  Thanks Roy.

In the datatracker, I've updated the RFC Editor note accordingly.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/