Subject: Re: bug#14128: web/http.scm: bad-header date check (UTC?)

From: Daniel Hartwig <[email-masked]>
Date: Wed, 3 Apr 2013 17:47:01 +0800

On 3 April 2013 15:59, Aleix Conchillo Flaqué <[email-masked]> wrote:
> Hi,
>
> I was doing a test using gnutls and connecting to twitter api
> services. Example attached.
>
> I successfully passed the TLS/SSL part, but then I got this HTTP bad
> header issue. I am running Guile 2.0.5 from Debian/unstable but
> current stable-2.0 branch also suffers from the safe problem (I
> think).
>
> =============
> 184: 1 [read-header #<input-output: gnutls-session-port 2e94c30>]
>  754: 0 [parse-asctime-date "Wed, 03 Apr 2013 07:29:49 UTC"]
>
> web/http.scm:754:6: In procedure parse-asctime-date:
> web/http.scm:754:6: Throw to key `bad-header' with args `(date "Wed,
> 03 Apr 2013 07:29:49 UTC")'.
> =============
>
> Basically, the problem is that web/http.scm only accepts a GMT suffix
> and the twitter server sends UTC. I think the RFC 822 standard accepts
> UT instead of UTC, so it would be wrong as well.

RFC 2616 _requires_ http date values have a suffix of " GMT", other
time zone values are not valid.  RFC 822 has no relevance.  Some times
you see these “API” or “web services” breaking HTTP spec. in various
ways and claiming “well we are not HTTP just very-HTTP-like” but that
is not useful for people trying to interact.

Turns out there are a few broken http servers around.  2616 recommends
to convert non-GMT date values to GMT where such conversion is
unambiguous, and in Guile we have done this a bit.  Apparently we are
supposed to do this a bit more and accomodate yet another
non-compliant service?

Erk.  What is the point of defining protocols and standards then?