W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 17 Jul 2012 07:56:14 +0200
Message-ID: <5004FE7E.9010300@gmx.de>
To: Mark Nottingham <mnot@mnot.net>
CC: Yutaka OIWA <y.oiwa@aist.go.jp>, Poul-Henning Kamp <phk@phk.freebsd.dk>, HTTP Working Group <ietf-http-wg@w3.org>
On 2012-07-17 02:21, Mark Nottingham wrote:
> On 17/07/2012, at 12:58 AM, Yutaka OIWA wrote:
>> Dear Poul,
>> 2012/7/16 Poul-Henning Kamp <phk@phk.freebsd.dk>:
>>> In message <CAMeZVwscuX986t9KMD0eXou-fgHUG8DBBkx2++AbJAt0gDs+Ng@mail.gmail.com>
>>> , Yutaka OIWA writes:
>>>>>> 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?
>>>> My personal proposal is instead of adding any examples, state it like "it may be
>>>> 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.
>> 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.
>>> 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.
>> +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?
> 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;
> ...

Sounds right to me.

Best regards, Julian
Received on Tuesday, 17 July 2012 05:56:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:02 UTC