Subject: Re: Issue 163, was: Meaning of invalid but well-formed dates

From: Mark Nottingham <[email-masked]>
Date: Sun, 23 May 2010 12:34:42 +1000

On 20/05/2009, at 12:35 AM, David Morris wrote:
> On Tue, 19 May 2009, Julian Reschke wrote:
> 
>> -> 50 years from when? Does the semantics of the message depend on when you look at it?
> 
> 50 years from now ... sure ... the problem with 2 digit years is well known and has been for more than 15 years. So this is simply a bad data fix up which has essentially no risk of a bad outcome. In the case where the recipient knows of a bad potential outcome for the wrong interpretation, such a date should be rejected ... (I don't feel a need to
> say this in the spec).

If we're going to disallow producing these dates when HTTPbis publishes, it seems like it would be reasonable to choose a fixed date -- say, Jan 1 2050?

I doubt that any valid HTTP messages were generated before 1950, and I *hope* that any remaining implementations that generate two-digit dates will be gone by 2050...

Cheers,

--
Mark Nottingham     http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Sun, 23 May 2010 11:45:21 +0200

> If we're going to disallow producing these dates when HTTPbis publishes, it seems like it would be reasonable to choose a fixed date -- say, Jan 1 2050?

Production of these date formats has been forbidden since RFC 2068 
(<http://tools.ietf.org/html/rfc2068#section-3.3.1>):

    HTTP/1.1 clients and servers that parse the date value MUST accept
    all three formats (for compatibility with HTTP/1.0), though they MUST
    only generate the RFC 1123 format for representing HTTP-date values
    in header fields.

> ...

Best regards, Julian

---

From: Henrik Nordström <[email-masked]>
Date: Mon, 24 May 2010 12:29:25 +0200

> I doubt that any valid HTTP messages were generated before 1950, and I *hope* that any remaining implementations that generate two-digit dates will be gone by 2050...

Is any such implementations seen today to a significant amount?

Note: The Squid implementation uses 1970-2070 for two digit years, and I
would expect quite many others doing the same considering limits of Unix
timestamps (0 == 1 Jan 1970).

Regards
Henrik

---

From: Dan Winship <[email-masked]>
Date: Mon, 24 May 2010 09:57:56 -0400

> timestamps (0 == 1 Jan 1970).

You definitely still see 2-digit years in Set-Cookie headers, and
draft-ietf-http-state-08 says to interpret them as 1969-2068 (presumably
allowing for the possibility that people might mistakenly convert 0 to a
date in their local timezone rather than UTC). If we're going to say
something, it would be nice to be consistent with that.

-- Dan

---

From: Henrik Nordström <[email-masked]>
Date: Mon, 24 May 2010 16:31:44 +0200

mån 2010-05-24 klockan 09:57 -0400 skrev Dan Winship:

> You definitely still see 2-digit years in Set-Cookie headers,

noted, but that's currently outside the HTTPbis specifications.

To precise my question:

Anyone seen a noticeable use of 2-digit dates used in any headers
covered by the HTTPbis specifications in the last years? And have thse
been otherwise correctly formed dates?

I have seen 2-digit dates some times, but from what I can remember those
have generally been malformed in other aspects as well using either
wrong timezone, localized day/month names etc.

Regards
Henrik