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

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;

> 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/

Received on Tuesday, 17 July 2012 00:21:29 UTC