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

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