Subject: [http-state] draft-ietf-httpstate-cookie-05 posted

From: Adam Barth <[email-masked]>
Date: Sun, 7 Mar 2010 10:50:57 -0800

My understanding is that Monday is the deadline for uploading I-Ds
before IETF77.  I've uploaded the latest version of the draft:

http://www.ietf.org/id/draft-ietf-httpstate-cookie-05.txt

If you're going to IETF77, this is the version of the draft that we'll
be discussing.  Looking forward to seeing many of you there.

Adam

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Thu, 11 Mar 2010 02:20:03 +0100

Hi,

> be discussing.  Looking forward to seeing many of you there.

Here are some comments about this draft

* "infelicities". While the general meaning is relatively obvious  from
context, IMO a more generally known phrasing should be chosen, e.g.
"unfortunate choices"

* Section 2. "General nonsense"? Maybe a more "appropriate" title should
be used?

* Maybe discuss race conditions when a cookie set by one response is
needed in the next request, but user interaction blocks the cookie for a
while. The user agent may have to delay sending requests to prevent user
experience problems. Additionally, such race conditions can occur if one
resource depends on a cookie being set by a separate request and the
dependent request is not dependably started after receipt of the cookie
in the first request.

* 3.1 examples

           "Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure, HttpOnly"

should be

           "Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly"

Comma is not allowed as a separator in Set-Cookie; it is used in RFC 2109
and 2965 to separate multiple cookies in the same header

* 4.1 definition of Max-age is missing. It is used in 5.2.1

* 4.1 Multiple Set-cookies in the same response with the same name and
scope
should not be used. Opera ignores cookies with the same name following an
unexpired cookie, including cookies set from other parallel requests (see
also race conditions, usually only a problem when the user is manually
accepting cookies) I have also observed that such multiple cookies in the
same requets can cause problems for sites when the client picks the
"wrong" cookie

* 4.1 sane-cookie-date should IMO discourage dates past 2036 due to 32-bit
time_t rollover, at least for the time being. Might recommend best
behavior for clients, and might suggest that using too long expiration
time should be avoided?

* 4.1 cookie-value should be token or quoted-string. Quotes are
particularly needed if the value contain restricted characters, like ";" .
RFC 2109 allows quoted string

* 4.1.2.2 The domain description should emphasize that cookies with
non-dotted domain attributes MUST be refused, the example should instead
be from a ccTLD, e.g. co.uk

* 5.1.1  delimiter  should include which ASCII character each hex value
represent in a comment

* 5.1.2 The domain parser should mention IDNA encoded names, and how to
process them. IMO, all names must be converted to A-label for purposes of
comparison, and server should/(must?) only send A-labels; although clients
may understand UTF-8 encoded names.

* 5.2.2 The expires should not be processed if there is a max-age
attribute. 5.3 does specify that max-age take precedence, but it might be
an idea to specify precedence elsewhere, too.

* 5.3 Have the name of "Mozilla Public Suffix list" been checked? just to
make sure the name is correct

* 5.3 step 10: Maybe specify that client must ignore cookies with
expiration date at the current time? (similar with use of "expiration date
in the past" elsewhere)

* 5.4 "elide" is  not a word I see frequently, and may be confusing to
some readers, though it is clear from the context. (I searched through 3
CDs of Baen ebooks and found the word used in just one book)

* 7.5 should mutually distrusting server on different machines in the same
domain  be mentioned? (even though it is mentioned somewhat in 7.6)

-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: Adam Barth <[email-masked]>
Date: Wed, 10 Mar 2010 18:23:03 -0800

Thanks for your detailed comments.  Responses inline.

On Wed, Mar 10, 2010 at 5:20 PM, Yngve N. Pettersen (Developer Opera
> context, IMO a more generally known phrasing should be chosen, e.g.

I'm going resist this editorial change for a bit longer.  I'll
probably eventually concede on this point though.  :)

> * Section 2. "General nonsense"? Maybe a more "appropriate" title should

I'm open to suggestions.  The term "general nonsense" comes from the
mathematics literature, where it refers to somewhat boilerplate
information that needs to be included for correctness.

> dependent request is not dependably started after receipt of the cookie

That's a good point to bring up.  I wasn't sure where to put that
warning, so I put it right before the examples.

[[
      <t>If a server sends multiple responses containing Set-Cookie headers
      concurrently to the user agent (e.g., when communicating with the user
      agent over multiple sockets), these responses create a "race condition"
      that can lead to unpredictable behavior.</t>
]]

> and 2965 to separate multiple cookies in the same header

Fixed.

> * 4.1 definition of Max-age is missing. It is used in 5.2.1

This is intentional.  The folks in the working group didn't think we
should recommend Max-Age to server operators because it's not
implemented in Internet Explorer.  I'm optimistic that IE will
implement it, but that's why it's not there.

> same requets can cause problems for sites when the client picks the

I made this slightly stronger:

[[
          <t>Servers SHOULD NOT include two Set-Cookie header fields in the
          same response with the same cookie-name.</t>
]]

Using the same cookie name in overlapping scopes is bad new bears.

> behavior for clients, and might suggest that using too long expiration

Done:

[[
          <t>To maximize compatibility with user agents, servers SHOULD use
          sane-cookie-dates before 2036 due to 32-bit "time_t" rollover.
          Hopefully the industry will resolve this issue in some way as 2036
          approaches.</t>
]]

> RFC 2109 allows quoted string

The quoted-string production is not widely implemented and explicitly
forbidden by this document.  See
<http://trac.tools.ietf.org/wg/httpstate/trac/ticket/2> for more
information.

> be from a ccTLD, e.g. co.uk

I've added .co.uk as an example here.  This section doesn't contain
any requirements on user agents, so anything more than advisory for
servers belongs in Section 5.  In Section 5, we describe the
requirements on user agents about this issue.  The requirements are on
the SHOULD-level, not the MUST-level, as discussed by the working
group in connection with Ticket 3 (search the archives for emails with
"Ticket 3" in the subject).

> * 5.1.1  delimiter  should include which ASCII character each hex value

There are too many of them.  I'd rather folks just wrote the hex
values in their code.  The ASCII representations are just nonsense.

> may understand UTF-8 encoded names.

This is <http://trac.tools.ietf.org/wg/httpstate/trac/ticket/10>.

> an idea to specify precedence elsewhere, too.

The spec has a few layers of abstraction.  In 5.2.2, we don't know
about other attributes.  The requirement is there in 5.3, which has a
slightly more global view.

> make sure the name is correct

What do you mean by has the name been checked?  The first hit on
Google for that term is the web site we intend to refer to.

> expiration date at the current time? (similar with use of "expiration date

I'm not too worried about that.  It's virtually impossible to hit the
current time on the dot.

> CDs of Baen ebooks and found the word used in just one book)

Elide is a perfectly good word that's been in the language for over
200 years.  :)

http://www.merriam-webster.com/dictionary/elide

> domain be mentioned? (even though it is mentioned somewhat in 7.6)

Well, the confidentiality problems there don't actually arise because
of the cookie protocol.  It's only when we use the cookie protocol
with an HTML user agent that we have a problem.  This issue is
discussed in the third paragraph of that section.  I guess we could
add a more pointed recommendation, but I don't think that's a mistake
that folks are likely to make given the text we have already.

Adam

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Thu, 11 Mar 2010 18:06:27 +0100

> information that needs to be included for correctness.

In some documents I've seen these are included in the introduction  
section, such as in RFC 2616

I have tended to reference syntax conventions at the beginning of the  
syntax section

>       that can lead to unpredictable behavior.</t>

Looks OK

> implement it, but that's why it's not there.

I still think it should be there, perhaps with a note that not all clients  
support it (Opera didn't until a couple of years ago), and that servers  
should complement it with an Expires attribute.

>           same response with the same cookie-name.</t>

OK

> Using the same cookie name in overlapping scopes is bad new bears.

Yes.

>           Hopefully the industry will resolve this issue in some way as  

OK

> <http://trac.tools.ietf.org/wg/httpstate/trac/ticket/2> for more

OK

> "Ticket 3" in the subject).

OK

> values in their code.  The ASCII representations are just nonsense.

But perhaps the more commonly used should be mentioned?

> This is <http://trac.tools.ietf.org/wg/httpstate/trac/ticket/10>.

Forgot about that correspondence.

> Google for that term is the web site we intend to refer to.

OK. I managed to dig up an email on the topic which also specifically uses  
that name.

> I'm not too worried about that.  It's virtually impossible to hit the

It is possible for "max-age=0"

> http://www.merriam-webster.com/dictionary/elide

It may be, but my point is mostly that it is AFAIK not frequently used.

---

From: Adam Barth <[email-masked]>
Date: Thu, 11 Mar 2010 09:41:03 -0800

On Thu, Mar 11, 2010 at 9:06 AM, Yngve Nysaeter Pettersen
<[email-masked]> wrote:
> In some documents I've seen these are included in the introduction section,
> such as in RFC 2616
>
> I have tended to reference syntax conventions at the beginning of the syntax
> section

Yeah, my concern is I'd like folks to read the introduction by I don't
care if people read that section because it doesn't say anything folks
don't already know...

> It is possible for "max-age=0"

That's a good point.  I'll read through all the time processing and
make sure these cases work correctly.

Adam

---

From: Adam Barth <[email-masked]>
Date: Thu, 11 Mar 2010 09:42:51 -0800

> should complement it with an Expires attribute.

Feel free to convince the working group on this point.  I support
describing it in Section 4.  It seems odd to leave out only one of the
attributes.

Adam

---

From: Daniel Stenberg <[email-masked]>
Date: Thu, 11 Mar 2010 22:05:34 +0100 (CET)

>          Hopefully the industry will resolve this issue in some way as 2036

Did you actually mean 2038 or is there any particular reason why there's a 
margin? See http://en.wikipedia.org/wiki/Year_2038_problem

-- 

  / daniel.haxx.se

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Fri, 12 Mar 2010 00:14:35 +0100

On Thu, 11 Mar 2010 22:05:34 +0100, Daniel Stenberg <[email-masked]> wrote:

> Did you actually mean 2038 or is there any particular reason why there's  
> a margin? See http://en.wikipedia.org/wiki/Year_2038_problem

As I recall, at least some years ago, the documentation for several 32-bit  
time_t functions I've used clearly specified that the conversion methods  
to/from time_t were only valid until a specific date in 2036.

-- 
Sincerely,
Yngve N. Pettersen

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 12 Mar 2010 10:47:36 +0100 (CET)

> to/from time_t were only valid until a specific date in 2036.

Can you or anyone else find/point to any closer details on this? I would like 
to see this somewhat explained next to the mention of the magic year 2036 as 
the 32bit limit does not really end until 2038 so I'm sure a few others than 
me who will suspect that 2036 might be a typo.

-- 

  / daniel.haxx.se

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Fri, 12 Mar 2010 12:07:38 +0100

On Fri, 12 Mar 2010 10:47:36 +0100, Daniel Stenberg <[email-masked]> wrote:

>>> Did you actually mean 2038 or is there any particular reason why  
>>> there's a margin? See http://en.wikipedia.org/wiki/Year_2038_problem
>>
>> As I recall, at least some years ago, the documentation for several  
>> 32-bit time_t functions I've used clearly specified that the conversion  
>> methods to/from time_t were only valid until a specific date in 2036.
>
> Can you or anyone else find/point to any closer details on this? I would  
> like to see this somewhat explained next to the mention of the magic  
> year 2036 as the 32bit limit does not really end until 2038 so I'm sure  
> a few others than me who will suspect that 2036 might be a typo.

IIRC correctly, the documentation for at least Visual Studio 3 had this  
note. And yes, it could have been a typo.

But using Year 2038 will be fine, too. But I think it should be made clear  
that using 2038 could cause problems since the rollover is in the early  
part of the year, so 2037 should be the last year used.

-- 
Sincerely,
Yngve N. Pettersen

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Mon, 15 Mar 2010 00:38:29 +0100

> describing it in Section 4.  It seems odd to leave out only one of the

IMO the syntax section of a specification should be complete enough that a  
reader can know "at a glance" what elements the possibilities the  
specification embodies, even if there are agents that are currently not  
using some of the syntax elements. There should be no "surprise"  
attributes that show up later in the document, whose existence cannot be  
derived from being part of some kind of syntax group.

If, as in this case, a particular element is not in use by at least one  
major client (plus older legacy clients), then that should be documented  
by at least a comment to the syntax, and other parts of the document  
should elaborate on that and specify how a server should use the attribute  
in an interoperable fashion.

There may be situations, such as in HTTP, where the exact details for a  
given header is specified in a section (or multiple sections) of its own,  
but even then the header is mentioned in the syntax summary.

While I would prefer the entire Max-age syntax in Section 4, one possible  
way to address the concerns mentioned could be to include a  
"max-age-attribute" element in Section 4, and then have the entire  
definition in the later section. IMO that would also look odd, and it is  
better to have the entire syntax in Section 4.

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Mon, 15 Mar 2010 01:00:57 +0100

> be discussing.  Looking forward to seeing many of you there.

Yet another possible issue, not sure if it has been mentioned in the group  
before (I have discussed it with others off-list):

* cookie-name should not be allowed to start with "$". I would prefer a  
MUST NOT, but a SHOULD NOT might be sufficient.

Given that the $-prefix has long been chosen for use in Version 1+ cookies  
(the syntax is also included in RFC 2109) this rule should be included to  
inform site administrators about this use in future versions, and that  
their use of such names could cause problems.

I am aware of at least a few servers that have used cookie names that  
start with "$", the major cluster of them being located around one  
specific US-state.

-- 
Sincerely,
Yngve N. Pettersen

---

From: Adam Barth <[email-masked]>
Date: Sun, 14 Mar 2010 23:03:04 -0700

On Sun, Mar 14, 2010 at 4:38 PM, Yngve Nysaeter Pettersen
<[email-masked]> wrote:
> using some of the syntax elements. There should be no "surprise" attributes
> that show up later in the document, whose existence cannot be derived from
> being part of some kind of syntax group.
>
> major client (plus older legacy clients), then that should be documented by
> at least a comment to the syntax, and other parts of the document should
> elaborate on that and specify how a server should use the attribute in an
> interoperable fashion.
>

I think you misunderstand the structure of the document.  Section 4 is
not about the syntax of the protocol.  It's about a subset of the
protocol that servers can use reliably.  I need to make that clearer
in the document.  The syntax of the protocol is defined in Section 5.

Adam

---

From: Adam Barth <[email-masked]>
Date: Sun, 14 Mar 2010 23:06:40 -0700

On Sun, Mar 14, 2010 at 5:00 PM, Yngve N. Pettersen (Developer Opera
Software ASA) <[email-masked]> wrote:
> * cookie-name should not be allowed to start with "$". I would prefer a MUST
> NOT, but a SHOULD NOT might be sufficient.

Do you mean that servers SHOULD NOT send cookie names that start with
$ or are you recommending some conformance requirement for user
agents?

Adam

> inform site administrators about this use in future versions, and that their
> use of such names could cause problems.
>
> I am aware of at least a few servers that have used cookie names that start
> with "$", the major cluster of them being located around one specific
> US-state.
>
> --
> Sincerely,
> Yngve N. Pettersen
>

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 15 Mar 2010 09:16:47 +0100 (CET)

> NOT, but a SHOULD NOT might be sufficient.

Have anyone tried to check how common such cookie names are? And related: are 
there existing widely used cookie implementations where using a such a name 
cause problems?

-- 

  / daniel.haxx.se

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Mon, 15 Mar 2010 10:54:39 +0100

On Mon, 15 Mar 2010 07:06:40 +0100, Adam Barth <[email-masked]> wrote:

>> MUST

Mostly as a server requirement.

Unless the requirement on servers is MUST NOT, it is not possible to add a  
requirement for clients. Although, if there is also text saying that  
clients MAY refuse cookies with names starting with $, that would  
certainly emphasize the point (and would be useful for clients supporting  
RFC 2965 or the proposed $Origin attribute).

RFC 2109 also says about name

       NAMEs that begin with $ are reserved for
       other uses and must not be used by applications.

Admittedly it is only only using small letters, but maybe it is time to  
strengthen that language?

-- 
Sincerely,
Yngve N. Pettersen

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Mon, 15 Mar 2010 10:54:45 +0100

On Mon, 15 Mar 2010 09:16:47 +0100, Daniel Stenberg <[email-masked]> wrote:

> Have anyone tried to check how common such cookie names are? And  
> related: are there existing widely used cookie implementations where  
> using a such a name cause problems?

Our information from our 2008 MAMA  
<http://dev.opera.com/articles/view/mama/ > spider run of 3.5 million URLs  
found 60 URLs that set cookies with names starting with $, but there were  
only 4 name variations, the largest group apparently originating with a  
single web development company with offices in North Carolina, South  
Carolina and Georgia, and websites for companies/cities in that area.

-- 
Sincerely,
Yngve N. Pettersen

---

From: Adam Barth <[email-masked]>
Date: Mon, 15 Mar 2010 09:06:48 -0700

On Mon, Mar 15, 2010 at 2:54 AM, Yngve N. Pettersen (Developer Opera
Software ASA) <[email-masked]> wrote:
> requirement for clients. Although, if there is also text saying that clients
> MAY refuse cookies with names starting with $, that would certainly
> emphasize the point (and would be useful for clients supporting RFC 2965 or
> the proposed $Origin attribute).

We've decided as a general principle that servers ought to be allowed
to use the full protocol specified in Section 5.  That implies we'd
add this requirement as a "SHOULD NOT" for servers.

> strengthen that language?

RFC 2109 says a lot of nonsense.  I'd rather focus on the facts on the
ground when making decisions.

Adam

---

From: Adam Barth <[email-masked]>
Date: Mon, 15 Mar 2010 09:08:53 -0700

On Mon, Mar 15, 2010 at 2:54 AM, Yngve N. Pettersen (Developer Opera
Software ASA) <[email-masked]> wrote:
>> Have anyone tried to check how common such cookie names are? And related:
>> are there existing widely used cookie implementations where using a such a
>> name cause problems?
>
> Our information from our 2008 MAMA <http://dev.opera.com/articles/view/mama/
>> spider run of 3.5 million URLs found 60 URLs that set cookies with names
> starting with $, but there were only 4 name variations, the largest group
> apparently originating with a single web development company with offices in
> North Carolina, South Carolina and Georgia, and websites for
> companies/cities in that area.

Hum...  That makes it sound like we shouldn't add a user agent
requirement on this topic until phase 2.

Adam

---

From: Julian Reschke <[email-masked]>
Date: Mon, 15 Mar 2010 17:14:46 +0100

On 15.03.2010 17:08, Adam Barth wrote:
> Software ASA)<[email-masked]>  wrote:
>> On Mon, 15 Mar 2010 09:16:47 +0100, Daniel Stenberg<[email-masked]>  wrote:
>> Our information from our 2008 MAMA<http://dev.opera.com/articles/view/mama/

Really?

It has been reserved, should be reserved, and seems to be only used 
*very* rarely...

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Mon, 15 Mar 2010 09:21:43 -0700

On Mon, Mar 15, 2010 at 9:14 AM, Julian Reschke <[email-masked]> wrote:
>>>> related:
>>> Our information from our 2008
>>> MAMA<http://dev.opera.com/articles/view/mama/
>>>>
> It has been reserved, should be reserved, and seems to be only used *very*
> rarely...

We're only supposed to require user agents to do things that are
already widely implemented.  I'll happily add this requirement if user
agents widely implement it, but that's not the case currently.
There's a bunch of stuff in RFC 2109 that's been "reserved" and
"should be reserved" but the reality today is that it isn't reserved.

Adam

---

From: Adam Barth <[email-masked]>
Date: Mon, 15 Mar 2010 09:23:42 -0700

> "should be reserved" but the reality today is that it isn't reserved.

Another perspective is that there's no big rush to add this
requirement.  It's probably not going to make user agents change their
behavior appreciably faster.  We might as well wait on moving the
mountain to phase 2.

Adam

---

From: Julian Reschke <[email-masked]>
Date: Mon, 15 Mar 2010 17:31:03 +0100

On 15.03.2010 17:23, Adam Barth wrote:
> ...

Don't require user agents to do anything specific. Just state that is 
has been reserved, continues to be reserved, and that servers must not 
use it.

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Mon, 15 Mar 2010 09:56:36 -0700

On Mon, Mar 15, 2010 at 9:31 AM, Julian Reschke <[email-masked]> wrote:
> Don't require user agents to do anything specific. Just state that is has
> been reserved, continues to be reserved, and that servers must not use it.

I agree that we should add a server requirement not to use cookie
names that begin with $.  I think it's more consistent with our
previous decisions to place the requirement at the SHOULD NOT level.
For example, currently Section 4 (which contains the server
requirements) doesn't have any MUST-level requirements.  If we're
going to add MUST-level requirements, then we should ban some of the
more ridiculous parts of the protocol before we ban use of $.

Adam

---

From: David Morris <[email-masked]>
Date: Mon, 15 Mar 2010 10:17:02 -0700 (PDT)

> "should be reserved" but the reality today is that it isn't reserved.

I interpret 'reserved' as an advisory term ... it doesn't place any new
requirement on User Agents but does warn the world that use is not 
considered appropriate. Since it is apparently know who some of the
design firms are, it might be a good approach to informally remind
them of the reserved status. 

Since the actual use is server controlled, it doesn't seem unreasonable
to expect a change could be implemented over the many months between when
this work is published as an RFC and when the first browser update
might decide to enforce the reservation... perhaps as an invalid cookie
warning popup?

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 15 Mar 2010 15:37:10 -0400

> >>          <t>To maximize compatibility with user agents, servers
> SHOULD
> >> use
> >>          Hopefully the industry will resolve this issue in some way
> as
> >> 2036
> >>          approaches.</t>
> >
> there's

The rollover definitely occurs in 2038 if using a signed 32-bit integer to
keep track of seconds since Jan 1, 1070.  However, I would recommend not
inserting language like this into the spec, because it assumes a certain
implementation.  Dates in the cookie spec themselves are not subject to this
issue, after all.

Didn't user agents already take this into consideration?  One could convert
dates to a string format like "2010-03-15T19:32:00Z" or simply use a 64-bit
integer similar to the Unix time_t type.  In any case, we should separate
the protocol from implementation, and there's nothing preventing one from
developing a user agent that handles the year 3054 if we so desired.  There
will likely always be a maximum year supported by a user agent and, if the
expiration date exceeds that year, I would assume that the user agent will
apply the maximum expiration time it supports.

Paul

---

From: Adam Barth <[email-masked]>
Date: Mon, 15 Mar 2010 12:40:11 -0700

> apply the maximum expiration time it supports.

User agents are required to handle these cases gracefully.  The
language we're considering is a recommendation for servers to improve
interoperability with some existing user agents that don't handle this
case gracefully.

Adam

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 15 Mar 2010 17:48:42 -0400

Adam,

> interoperability with some existing user agents that don't handle this

If a UA today would do something strange, the UA needs to be fixed.  I'm
concerned with inserting language that requires behavior to try to overcome
issues with user agents.  Do such issues exist in practice?  If so, we ought
to fix the browser.

Also consider that it's not the web server that will generate cookies, but
many thousands of application developers will create cookies and specify
expiration dates.  There are just a handful of browser vendors.

When one of these thousands of app developers passes an expiration date of
2050 over the wire and a browser breaks, do we blame the application
developer who composed a proper date or the browser vendor who didn't give
the date reasonable treatment? This language suggests we blame the app
developer, but I don't think that's where blame should be placed.

The UA might want to change the date to 2037 internally and I doubt anybody
would care.  I don't even think that's something noteworthy since the UA
will not likely be around by then.  What is important is that the UAs at
least give reasonable treatment of dates beyond 2038.

Paul

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 15 Mar 2010 22:54:30 +0100 (CET)

> expiration dates.  There are just a handful of browser vendors.

Ehum.

We're taking HTTP cookies here: they are implemented and used client-side by 
way more implementations than "a handful of browser vendors".

I'm not saying that changes the argument, I just want things right.

-- 

  / daniel.haxx.se

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 15 Mar 2010 22:57:55 +0100 (CET)

On Mon, 15 Mar 2010, Adam Barth wrote:

> The language we're considering is a recommendation for servers to improve 
> interoperability with some existing user agents that don't handle this case 
> gracefully.

Do we actually know of such existing user agents?

-- 

  / daniel.haxx.se

---

From: Adam Barth <[email-masked]>
Date: Mon, 15 Mar 2010 15:10:20 -0700

On Mon, Mar 15, 2010 at 2:48 PM, Paul E. Jones <[email-masked]> wrote:
> If a UA today would do something strange, the UA needs to be fixed.

The spec already requires UAs to handle this case.  As I said above,
this language is in the spec as advice to help servers deal with
existing UAs that do not comply with the spec.  By definition, the UAs
we're concerened about here cannot be fixed.

> I'm concerned with inserting language that requires behavior to try to overcome
> issues with user agents.

That's how the web works.

> Do such issues exist in practice?  If so, we ought to fix the browser.

I haven't tested browsers, but I do know of these sorts of issues
occurring in HTTP caching headers, for example in IE6.

> expiration dates.  There are just a handful of browser vendors.

So?

> developer, but I don't think that's where blame should be placed.

I'm not very interested in the blame game.  The spec requires UAs to
handle these far-future dates in a reasonable way.  The spec also
recommends servers avoid using these dates because of interoperability
issues.  If we find a case where the server is using such a date and
the UA is having trouble processing it, I'd recommend that both the
server and the UA change.

> would care.

That is, in effect, what the spec has the UA do.

> I don't even think that's something noteworthy since the UA

That is required by the current draft.

> Do we actually know of such existing user agents?

I don't have specific knowledge of any such existing user agents.
However, I haven't tried testing for the issue either.

Yngve, was your recommendation motivated by the behavior of any
particular user agent?

Adam

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 15 Mar 2010 19:20:59 -0400

Daniel,

> I'm not saying that changes the argument, I just want things right.

Some cookies might be created client-side in JavaScript, for example, but
the particular text we're referring to in the security section talks about
cookies generated by the server.

My point is that thousands of application developers using a wide variety of
tools (perl, python, Ruby, PHP, etc.) generate cookies.  This is not really
the "server", but the server application. While that might be a minor nit,
my primary point was that there are loads of developers generating cookies
server-side, but there are only a small handful of browsers that need to
handle those cookies.  Further, the browsers *must* be able to do something
intelligent with a cookie that is syntactically correct and has a year that
is beyond 2038.

Thus, I think the requirement (or recommendation, actually) for proper
treatment should be on the client (browser), not the server or server
application.  What would be the justification for a browser to not provide
reasonable treatment of a cookie set to expire in 2050?

Paul

---

From: Daniel Stenberg <[email-masked]>
Date: Tue, 16 Mar 2010 00:29:57 +0100 (CET)

On Mon, 15 Mar 2010, Paul E. Jones wrote:

> there are only a small handful of browsers that need to handle those 
> cookies.

I'm claiming that statement is wrong.

Cookies are handled client-side by HTTP clients that handle cookies. There are 
far more such client implementations in wide use than "just" the major 
browsers, like for example the library I myself work with: libcurl. But there 
are a large number of other implementations of tools and libraries handling 
cookies that are used out there.

Most probably not at all as many as the server-side apps creating the cookies, 
but certainly not limited to "a small handful of browsers".

-- 

  / daniel.haxx.se

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 15 Mar 2010 19:52:18 -0400

Adam,

> we're concerened about here cannot be fixed.

But, are there UAs that truly have a problem with the cookie expiration
time?  If so, this is a bug and we should not change the protocol (which
this recommendation does, in effect) due to such an isolated bug.  Perhaps
it might be noteworthy to have in a blog somewhere that browser X has this
limitation, but it does not seem appropriate for the standard, because I
would not want to encourage application server developers to impose some
artificial limit like this.
 
> That's how the web works.

I don't understand what you mean by this statement.
 
> occurring in HTTP caching headers, for example in IE6.

While IE6 still clings to corporate walls, me, you, and everybody --
including Microsoft -- agrees that it's long past time for this browser
release to disappear.  And, I believe the corporate world has received that
message and I am seeing a decline in IE6 usage.  This specification will
provide guidance for years (perhaps decades), so we ought not force server
application developers to consider (for too long) such interop issues.  This
is but 1 of many, many things people have to deal with for IE6 -- if it is
even a problem at all.  I would have guessed that MS would have changed any
future date in 0x7FFFFFFF if they do use time_t.  And, that's OK.
 
> > expiration dates.  There are just a handful of browser vendors.

There will be thousands of web developers who do not look at this spec.  I
expect every browser vendor will have a team that reads this spec.  With
just a few browser vendors and everybody reading the spec and understanding
that dates might be years like 5243, then I would expect a greater chance of
handling the date in some "sane" manner.  And, that "sane" manner might be
to not use a 32-bit time_t. 
 
> server and the UA change.

And both might change.  Application developers, as I mentioned, already work
around all kinds of UA inconsistencies.  Even so, the text provides guidance
to web server developers to NOT use dates beyond 2036 (which I assume you'll
change to 2038) to maximize compatibility.  This is like a stamp of approval
for UAs to not support longer dates.

I'd be O with something like:
It should be noted that some older user agents that utilize a 32-bit signed
time_t data type to store the cookie expiration time might not properly
support dates much beyond 2037.  If support of such legacy user agents is
important, application developers should take care to use sane-cookie-dates
before 2038.

Perhaps the word "legacy" is too strong and could be replaced with "older".
But, I think that captures your intent to provide caution, but also
highlights the fact that it's not desirable for UAs to have this limitation.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 15 Mar 2010 19:57:39 -0400

Daniel,

> but certainly not limited to "a small handful of browsers".

Ah, yes... I understand your point now, and you're right.

However, the fact you're engaged in this draft speaks to the point I tried
to make: those building UAs are likely going to read this spec.  I would
venture to guess there will be thousands of application developers
generating cookies that never read this spec.

Paul

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Tue, 16 Mar 2010 15:14:09 +0100

> Yngve, was your recommendation motivated by the behavior of any

No.

However, I've just confirmed that many of compilers for the device  
(non-desktop) platforms we are delivering on are using a 32 bit time_t.

At the very least this could indicate that other clients are also limited
by 32 bit, and might using conversion functions that return an error value
instead of an upper limit date when the year is outside the allowed range.
At best this could mean that the cookie is converted to a session cookie.

Opera is currently enforcing an upper limit of 2036 for dates on the form
used for Expires (I have filed a bug on that). There is no such limit for
max-age, except the max value that can be represented.

I wonder if the Expires/Max-age should discourage using values more than a
few years into the future. One thing is that it is unlikely that the
client will exist as long (but that to the end of client existence aspect
is probably what the designer want); another is that the server will have
to maintain a database for those sessions for a very long time, possibly
leading to a lot of storage overhead; a third is that quite a few people
frown upon the use of long-lasting cookies. Maybe a recommendation of "not
more than" 2 or 3 years should be added as a best-practice?

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 16 Mar 2010 13:20:01 -0400

> more than" 2 or 3 years should be added as a best-practice?

I think that's a reasonable recommendation, since such cookies waste space
and might be viewed as a privacy concern by some.  We've seen stories about
user outcry over long-lived "tracking" cookies and such.  Perhaps we might
even go a step further and say that the UA may reduce the expiration time as
it sees fit.

Paul

---

From: Adam Barth <[email-masked]>
Date: Tue, 16 Mar 2010 10:43:36 -0700

On Tue, Mar 16, 2010 at 10:20 AM, Paul E. Jones <[email-masked]> wrote:
> user outcry over long-lived "tracking" cookies and such.

Ok.  I'll spin up some text along these lines.

> Perhaps we might

The spec already lets user agents delete any cookie at any time
because many user agents expose UI to let users delete cookies in
various ways.

Adam

---

From: Dan Witte <[email-masked]>
Date: Tue, 16 Mar 2010 11:06:42 -0700 (PDT)

> because many user agents expose UI to let users delete cookies in

There's also a common case that's more common than people may think -- Firefox, at least, evicts cookies once the maximum table size (3000 entries) is reached, but only for cookies greater than 30 days old. People who browse many sites daily easily hit this 30 day limit. More casual users will still hit it within a few months, typically.

So, for our users at least, cookie expiries longer than, say, 6 months are pretty meaningless. :)

Regards,
Dan