- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 17 Jul 2012 07:56:14 +0200
- 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