Subject: [http-state] wrt 2-digit years in expires attribute (was: Re: Comments on draft-ietf-httpstate-cookie-08.txt ...)

From: =JeffH <[email-masked]>
Date: Wed, 01 Sep 2010 16:17:23 -0700

Bjoern Hoehrmann <[email-masked]> most recently replied:
 >
 > Adam Barth <[email-masked]> had replied:
 >>
 >> Bjoern had replied:
 >>>
 >>> Adam had replied:
 >>>>
 >>>> Bjoern had stated:
 >>>>>
 >>>>> The surprising requirements in this section need to be accompanied by
 >>>>> some rationale, for example, accepting 1601 as year but not 1600 is
 >>>>> surprising and so is the 68/69 boundary.
 >>>>
 >>>>The reason is just that's how the protocol works.  It's odd, but
 >>>>that's how it works.
 >>>
 >>> I think it is unlikely that surprising requirements will be widely im-
 >>> plemented unless the reasoning behind them is explained.
 >>
 >>That requirement is already widely implemented, so we have nothing to fear here.
 >
 > Well, the draft requires the 19XXs to start with 1969, Gecko/20100529
 > and Opera 10.51 use 1970, Internet Explorer 6 uses 1980. The draft re-
 > quires to ignore the Expires attribute if the year is below 1601, and
 > Opera 10.51 rather treats all years before 1900 as 2036 (on my system
 > anway). That is not my understanding of "widely implemented".

Daniel Stenberg <[email-masked]>  noted today:
 >
 > I just did a test that sets 100 cookies in this format:
 >
 >      Set-Cookie: test$yy=set; expires=Wed Oct  1 22:01:55 $yy;
 >
 > When the user reloads this page, the page prints all "test$yy" cookies that
 > get sent to the server. The results with the various browsers is very
 > interesting. These are the ranges the browsers think are future:
 >
 >     Firefox:   21 - 69 (and Fennec and MicroB on n900)
 >     Chrome:    10 - 68
 >     Konqueror: 00 - 99 (and Links and Netsurf)
 >     curl:      10 - 70
 >     Opera:     41 - 69 (and Opera Mobile)
 >     IE8:       31 - 79
 >     Midori:    10 - 69 (and IBrowse)
 >     w3m:       10 - 37
 >     AWeb:      10 - 77
 >
 > (Rough) summary:
 >
 >     0-9:   mostly in the past
 >     10-20: almost always in the future except Firefox
 >     21-30: even more likely to be in the future except IE8
 >     31-37: everyone but opera thinks this is the future
 >     38-40: now w3m and opera think this is the past
 >     41-68: everyone but w3m thinks this is the future
 >     69:    Chrome and w3m say past
 >     70:    curl, IE8, Konqueror say future
 >     71-79: IE8 and Konqueror say future, everyone else say past
 >     80-99: Konqueror say future, everyone else say past
 >
 > Conclusion:
 >
 >    There is not a single 2-digit year that all clients agree is in the past
 >    or in the future.

I had today noted:
 >
 > Ok, so the issue with the spec AFAICT is not /just/ with year tokens of '69',
 > but with these two rules from section 5.1.1. "Dates"...
 >
 >     3.  If the year-value is greater than 68 and less than 100, increment
 >         the year-value by 1900.
 >
 >     4.  If the year-value is greater than or equal to 0 and less than 69,
 >         increment the year-value by 2000.

Well, I suppose one approach we can do is massage these two algorithm steps to 
somehow be SHOULDs, use 2-digit year ranges that are pretty much the union of 
FF+Chrome+IE behavior, and perhaps append Daniel's above info as an appendix.

When we initially began this work (a year+ ago now), we tacitly agreed that 
we'd write into the spec what we wanted/wished the browser implementor 
community to converge on in the case we discovered egregious divergence on some 
aspect of cookie processing. Seems like the above qualifies as (pathologically) 
"divergent".

thoughts?

=JeffH