Subject: [http-state] Testing all 2-digit years in 'expires'

From: Daniel Stenberg <[email-masked]>
Date: Thu, 2 Sep 2010 00:25:28 +0200 (CEST)

Hi again.

Man, this turned out to be a lot of fun and giggling... :-)

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.

How to test a browser near you:

  1. goto http://daniel.haxx.se/cookie2.cgi
  2. reload once
  3. the numbers shown on the screen is the year numbers the browsers consider
     to be the future as described above

-- 

  / daniel.haxx.se

---

From: Adam Barth <[email-masked]>
Date: Wed, 1 Sep 2010 15:39:22 -0700

Thanks Daniel.  This is very useful data.  Given that many
implementations seem to switch over around the end of the sixties /
early seventies and given that the unix epoch begins on 1 January
1970, it seems sensible to set the cutover year as follows:

00-69 => 2000-2069
70-99 => 1970-1999

Thoughts?

Adam

On Wed, Sep 1, 2010 at 3:25 PM, Daniel Stenberg <[email-masked]> wrote:
> _______________________________________________
> http-state mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-state
>

---

From: Daniel Stenberg <[email-masked]>
Date: Thu, 2 Sep 2010 00:42:27 +0200 (CEST)

On Wed, 1 Sep 2010, Adam Barth wrote:

> Thanks Daniel.  This is very useful data.  Given that many implementations 
> seem to switch over around the end of the sixties / early seventies and 
> given that the unix epoch begins on 1 January 1970, it seems sensible to set 
> the cutover year as follows:
>
> 00-69 => 2000-2069
> 70-99 => 1970-1999
>
> Thoughts?

I think it makes sense as a recommendation as how to treat them, although 
quite clearly many existing implementations think in more complicated terms.

-- 

  / daniel.haxx.se

---

From: Dan Winship <[email-masked]>
Date: Wed, 01 Sep 2010 21:39:05 -0400

>     Set-Cookie: test$yy=set; expires=Wed Oct  1 22:01:55 $yy;

It might be more useful to test "Wed, 01-Oct-$yy 22:01:55", which was

>    Konqueror: 00 - 99 (and Links and Netsurf)

is probably just saying "I don't know how to parse that date, so I'm
going to treat it as a session cookie". Likewise,

>    IE8:       31 - 79 

seems like it might be interpreting the $yy as the day of the month when
that would be valid for the indicated month (and presumably treating the
"1" as the year in that case).

-- Dan

---

From: Dan Witte <[email-masked]>
Date: Wed, 1 Sep 2010 19:01:19 -0700 (PDT)

----- Original Message -----
> get sent to the server.

Did you account for the cookie-per-host limits in your test?

Firefox will cap at 50, so you'll only get the most recent ones you set.

Dan

---

From: Daniel Stenberg <[email-masked]>
Date: Thu, 2 Sep 2010 06:59:33 +0200 (CEST)

On Wed, 1 Sep 2010, Dan Winship wrote:

> actually once a legitimate date format.

It could be, yes. I'm aware that the date format I used is "funny" but it is 
then a test on how the client treats the number when it appears somewhere 
unexpected.

I'm sure your format suggestion would cause at least minor differences in 
results.

I don't think it matters that much though for the overall case.

-- 

  / daniel.haxx.se

---

From: Daniel Stenberg <[email-masked]>
Date: Thu, 2 Sep 2010 07:03:30 +0200 (CEST)

> Did you account for the cookie-per-host limits in your test?

No. I described the exact process: 100 cookies named testYY. The only thing I 
didn't mention is that I set an extra cookie named 'works' to see that the 
date format is accepted with 4 digits for the year.

> Firefox will cap at 50, so you'll only get the most recent ones you set.

Great point and thanks for the hint. This explains the funny start year of 21 
then as 10 to 20 most likely went over the cookie-per-host limit.

-- 

  / daniel.haxx.se

---

From: Daniel Stenberg <[email-masked]>
Date: Thu, 2 Sep 2010 15:03:19 +0200 (CEST)

On Thu, 2 Sep 2010, Daniel Stenberg wrote:

> Great point and thanks for the hint. This explains the funny start year of 
> 21 then as 10 to 20 most likely went over the cookie-per-host limit.

Just to close this loose end:

I upped the limit to 200 per host and yes then Firefox considers 10-69 to be 
the future.

-- 

  / daniel.haxx.se