Subject: Re: [http-state] IETF-wide Last Call for -httpstate-cookie-10 ?

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 01 Sep 2010 13:36:15 -0600

On 8/27/10 4:22 PM, Bjoern Hoehrmann wrote:
> * Adam Barth wrote:
>> According to <http://www.ietf.org/mail-archive/web/http-state/current/msg00834.html>,
>> I seem to have asked you for a test case, which I don't have a record
>> of you ever providing:
> 
> I did not. Knowing nothing about your test suite I could only have pro-
> vided a Set-Cookie header with a date in 1969. You would spend more time
> asking me to make one, wait for and then read through the response, then
> verify the test case and incorporate it into your test suite, than just
> making the test case yourself, so I didn't think you were being serious.
> 
>> In any case, the test suite isn't done yet and it's not a prerequisite
>> for finishing this document.
> 
> The idea wasn't to add something to your test suite, but to change the
> draft so it defines date processing in line with major implementations
> (that being a goal of the specification) or note in the document why it
> defines something that is unintuitive and contrary to running code, so
> implementers may be persuaded to change their implementations.

If the date processing behavior of existing implementations is an open
issue, then perhaps the WG can settle on the correct wording via list
discussion, or add the issue to the tracker:

http://trac.tools.ietf.org/wg/httpstate/trac/report/1

Do correct me if I'm wrong, but as far as I can see date processing
behavior is the only open issue -- the other topics in this thread were
requests for new features, not clarifications of existing behavior for
documentation in draft-ietf-httpstate-cookie.

Peter

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

---

From: Daniel Stenberg <[email-masked]>
Date: Wed, 1 Sep 2010 22:30:50 +0200 (CEST)

> discussion, or add the issue to the tracker:

I setup a little CGI that can be used to check what your browser thinks:

 	http://daniel.haxx.se/cookie.cgi

It sends a single cookie header that looks like:

 	"Set-Cookie: testme=yesyes; expires=Wed Sep  1 22:01:55 69;"

The script prints the Cookie: headers, so if you reload you should see 
"testme=yesyes" being output if the cookie is still there. If the cookie is 
still there, your browser of choice treats the date above as a date in the 
future.

My friends and I did a quick round and we tested a few browsers:

Future:

   Firefox (2069)
   curl (2147483647 seconds)
   IE 7 (2069)
   Opera (year 2036)
   Android

Historic:

   Chrome (both v4 and v5)

Conclusion:

Most clients seem to agree that '69' refers to '2069'.

-- 

  / daniel.haxx.se

---

From: Adam Barth <[email-masked]>
Date: Wed, 1 Sep 2010 13:40:40 -0700

> Most clients seem to agree that '69' refers to '2069'.

Thanks Daniel, That's very helpful.

Adam

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 06 Sep 2010 04:52:26 +0200

>documentation in draft-ietf-httpstate-cookie.

This was just the first thing that came to mind as I went through the
trouble of actually testing what browsers do. Another issue that is
still present in the latest draft is that the "well-behaved profile"
prohibits strings in the "Domain" attribute that start with a digit,
http://www.ietf.org/mail-archive/web/http-state/current/msg00867.html

I would have to read through the list archive and review the latest
draft to come up with a complete list of unresolved issues. I've yet
to complete my first read through the draft, so I'm unlikely to find
the time to do that.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/