Subject: [http-state] Parsing the Date header (was Re: Ticket 6: host-only cookies)

From: Adam Barth <[email-masked]>
Date: Fri, 29 Jan 2010 10:11:37 -0800

On Fri, Jan 29, 2010 at 6:23 AM, Dan Winship <[email-masked]> wrote:
> On 01/29/2010 03:38 AM, Adam Barth wrote:
>> There's also a minor point about parsing the Date header:
>>
>> [[
>> Let server-date be the date obtained by parsing the contents of
>> the last Date header field as a cookie-date.
>> ]]
>>
>> http://tools.ietf.org/html/draft-ietf-httpstate-cookie-02#section-5.2.2
>>
>> I'm not sure whether that's a big deal though.
>
> 2616 and httpbis both say:
>
>      Note: Recipients of date values are encouraged to be robust in
>      accepting date values that may have been sent by non-HTTP
>      applications
>
> So, you're ok.
>
> Though I'm not convinced the text is needed; the Date header is most
> likely generated by a lower-level part of the server stack that was
> written by people who are actually aware of the relevant specs. When I
> was logging my cookie traffic a few years ago, despite all the
> variations I found in cookie Expires attributes, I only found a single
> non-rfc1123 Date header, and that was from a guy who had written his own
> http server. (And he'd actually already noticed that bug and fixed it,
> but not yet deployed the fixed version yet.)

That's an interesting data point.  I'm happy to refer to HTTP for
interpreting the Date header if we don't need the wacky cookie-date
parser for compatibility.

One subtly is that part of the reason with have this date arithmetic
is to compensate for servers that have large clock skew or use non-GMT
timezones.  In particular, the cookie-date parser ignores any timezone
decorations.  We want to make sure whatever parser we use for the Date
header does the same thing so that when we subtract them we get the
"right" relative time.

Adam