Subject: #375: Most Conservative (caching and date parsing)

From: Mark Nottingham <[email-masked]>
Date: Mon, 16 Jul 2012 16:28:01 +1000

<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/375>

> If an HTTP header field incorrectly carries a date value with a time zone other than GMT, it must be converted into GMT using the most conservative possible conversion.

What does "most conservative" mean?

"Earliest" makes sense for Expires and Date, but Last-Modified it would seem that "latest" is the most conservative. 

I really don't want to create a registry -- or even another aspect that each header has to define -- here.

Maybe just a few examples would help?

Regards,

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

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 16 Jul 2012 20:45:27 +1200

> "Earliest" makes sense for Expires and Date, but Last-Modified it would seem that "latest" is the most conservative.

Precisely. Is any different view of "conservative" possible?

> Maybe just a few examples would help?

Or moving the error recovery into the header definitions with 
appropriate differences? As you note there is no one fix that fits all 
date usages.

AYJ

---

From: Yutaka OIWA <[email-masked]>
Date: Mon, 16 Jul 2012 22:47:15 +0900

Dear Mark and Amos,

> "Earliest" makes sense for Expires and Date, but Last-Modified it would seem that "latest" is the most conservative.

For Expires, I agree.  For the latter two cases it seems to be
depending on further application contexts.

Also, I argue how to determine possible choices from which the
"conservative" one is chosen.
If some implementers are willing to follow the "must be" request,
should they have
tables of all possible time-zone conversions and conflicts like below?

CST: American Central Standard Time (-6) or China Standard Time (+8)
and two more
EST: American Eastern Standard Time (-5) or Australian Eastern
Standard Time (+10)
(much more conflicts exist)

# http://www.timeanddate.com/library/abbreviations/timezones/ lists up
# 4 different offsets for CST, 3 for IST, CDT and WST, and 2 for many symbols.

My personal proposal is instead of adding any examples, state it like "it may be
converted to GMT using whatever methods they think appropriate", emphasizing
senders' responsibility for sending GMT times.  This text still allows
implementers
to convert CST to either -5 or -6 or +8 or +9.30 according to their
applications'
nature or request IP address or whatever information available,
or to choose the "appropriately conservative" one between -5 and +9.30.

-- 
Yutaka OIWA, Ph.D.              Leader, Software Reliability Research Group
                             Research Institute for Secure Systems (RISEC)
   National Institute of Advanced Industrial Science and Technology (AIST)
                     Mail addresses: <[email-masked]>, <[email-masked]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 16 Jul 2012 14:23:14 +0000

In message <[email-masked]>

>converted to GMT using whatever methods they think appropriate", 

As a time-geek, I would caution against that, because names of timezones
are politically chosen and both their definition and naming is highly
fragile in various parts of the world.

Given that it is a class-A fuckup to send wrong dates, I will advocate
that such timestamps SHOULD be ignored, but CAN be interpreted on a
best-effort basis.

Ohh, and also:  GMT is (maybe!) what parliament decides in the UK, the
correct "independent" timescale is called UTC.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Yutaka OIWA <[email-masked]>
Date: Mon, 16 Jul 2012 23:58:53 +0900

Dear Poul,

> fragile in various parts of the world.

Yes, that's why I am proposing to remove any clauses that
morally require people to parse wrong dates "correctly".
I think my proposal is along with, not against your suggested direction.
# The original text requests people to parse these appropriately and
conservatively.

> that such timestamps SHOULD be ignored, but CAN be interpreted on a

+1 on default to ignore.  That's one step further beyond my proposal and
it makes sense.
But I am not sure, are there any HTTP date-related headers for which
ignoring is more dangerous than guessing?

> correct "independent" timescale is called UTC.

This is very historic :-)  In HTTP, GMT *is* the mnemonic for the Universal
Coordinated Time, independent from any local time standards of UK.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 16 Jul 2012 15:18:14 +0000

In message <[email-masked]>

>ignoring is more dangerous than guessing?

I would hope so, that would increase the chance of people noticing
and fixing the bugs.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 17 Jul 2012 10:21:01 +1000

> ignoring is more dangerous than guessing?

Perhaps the simplest thing, then, is to change the requirement to:

    HTTP header fields with time zones other than "GMT" SHOULD be considered invalid.

Our approach to conformance already allows implementations to try to recover an invalid field, but the responsibility (and risk) is upon them when doing so.

Expires can't be ignored, but it already defines what to do when it's invalid;

> A cache must treat other invalid date formats, especially including the value "0", as in the past (i.e., "already expired").

Cheers,

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

---

From: Julian Reschke <[email-masked]>
Date: Tue, 17 Jul 2012 07:56:14 +0200

On 2012-07-17 02:21, Mark Nottingham wrote:
> ...

Sounds right to me.

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 17 Jul 2012 06:20:58 +0000

>> Expires can't be ignored, but it already defines what to do when it's invalid;

And me too.

... even though it pains my inner time-nut that "UTC" would not
be an acceptable alias for UTC in this case :-)

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 18 Jul 2012 11:04:49 +1000

OK. Marking for incorporation, with a slight change;

  Caches SHOULD consider dates with time zones other than "GMT" invalid.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 18 Jul 2012 09:50:52 +0200

>    Caches SHOULD consider dates with time zones other than "GMT" invalid.

-> <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1814>

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 18 Jul 2012 21:16:51 +1200

> -> <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1814>

+1.

AYJ