GNU bug report logs - #13544
(web http) fails to parse numeric timezones in Date header

Previous Next

Full log

View this message in rfc822 format

From: Daniel Hartwig <mandyke <at> gmail.com>
To: Andy Wingo <wingo <at> pobox.com>
Cc: Ludovic Courtès <ludo <at> gnu.org>, 13544 <at> debbugs.gnu.org, Cyril Roelandt <tipecaml <at> gmail.com>
Subject: bug#13544: (web http) fails to parse numeric timezones in Date header
Date: Sat, 9 Mar 2013 09:41:46 +0800

On 8 March 2013 06:28, Andy Wingo <wingo <at> pobox.com> wrote:
> On Thu 24 Jan 2013 23:13, ludo <at> gnu.org (Ludovic Courtès) writes:
>
>> scheme@(guile-user)> (use-modules(web client)(web uri))
>> scheme@(guile-user)> (http-get (string->uri "http://www.sqlite.org/"))
>> web/http.scm:768:6: In procedure parse-asctime-date:
>> web/http.scm:768:6: Bad Date header: Thu, 24  Jan 2013 21:53:01 +0000
>
> As you can see here:
>
>   http://pretty-rfc.herokuapp.com/RFC2616#date-time-formats
>
> HTTP doesn't actually support other time zones.  The date header being
> reported by sqlite.org is invalid.

Correct, though ‘+0000’ is the right time zone, just the format is
wrong (according to RFC 2616).  A survey of HTTP sites I performed
last year as research for another header issue in Guile showed
something like 1% of those sites using the numeric timezone format,
contrary to the specification.  This is likely due to false reliance
on RFC 1123 (quoted by Ludo in the original report), which indicates a
preference for numeric timezones that are are indirectly forbidden by
RFC 2616 (which states, timezone must be the string “GMT”)

Interpretting ‘+0000’ timezone is sensible in a robust implementation,
though what to do if a numeric timezone is given other than this?
Convert it to GMT is one option, since the spec. defines that the
header must be in this timezone.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.