GNU bug report logs - #10147
HTTP "Expires" header should handle non-date values

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Daniel Hartwig <mandyke <at> gmail.com>
Subject: bug#10147: closed (Re: bug#10147: HTTP "Expires" header should
 handle non-date values)
Date: Mon, 09 Jan 2012 22:38:03 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#10147: HTTP "Expires" header should handle non-date values

which was filed against the guile package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 10147 <at> debbugs.gnu.org.

-- 
10147: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10147
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Andy Wingo <wingo <at> pobox.com>
To: Daniel Hartwig <mandyke <at> gmail.com>
Cc: guile-user <at> gnu.org, 10147-done <at> debbugs.gnu.org
Subject: Re: bug#10147: HTTP "Expires" header should handle non-date values
Date: Mon, 09 Jan 2012 23:36:44 +0100

Hi Daniel,

Thanks very much for the thorough analysis!

On Tue 27 Dec 2011 16:49, Daniel Hartwig <mandyke <at> gmail.com> writes:

> Given those points, I have attached a patch implementing the suggested
> handling for "Expires" and will take a look at perhaps relaxing
> parse-date (and others).  Anyone have ideas on that?

I applied your patch, and I think some sensible parse-date relaxations
are a good idea too.

Regards,

Andy
-- 
http://wingolog.org/

[Message part 3 (message/rfc822, inline)]

From: Daniel Hartwig <mandyke <at> gmail.com>
To: "R. P. Dillon" <rpdillon <at> gmail.com>
Cc: bug-guile <at> gnu.org, guile-user <at> gnu.org
Subject: HTTP "Expires" header should handle non-date values
Date: Sun, 27 Nov 2011 18:39:12 +0800

[Message part 4 (text/plain, inline)]

Package: guile
Version: 2.0.3
Tags: patch

On 6 November 2011 13:49, R. P. Dillon <rpdillon <at> gmail.com> wrote:
> (use-modules (web request) (web response) (web uri) (rnrs bytevectors))
> (define port (socket PF_INET SOCK_STREAM 0))
> (define address (addrinfo:addr (car (getaddrinfo "www.google.com" "http"))))
> (connect port address)
> (define request (build-request (build-uri 'http #:host "www.google.com")))
> (write-request request port)
> (define response (read-response port))
> (read-response ...) consistently fails with Google:
> web/http.scm:754:6: In procedure parse-asctime-date:
> web/http.scm:754:6: Throw to key `bad-header' with args `(date "-1")'.
> The expiration is set to -1 in the headers, and this seems to cause a
> problem for the web libraries in Guile.
> This same request seems to work well for my own domain (killring.org).

This is definitely a bug on Guile's part, HTTP/1.1 permits such values
for "Expires" headers [1], treating them as though they were a date in
the past:

   HTTP/1.1 clients and caches MUST treat other invalid date formats,
   especially including the value "0", as in the past (i.e., "already
   expired").

[1] http://tools.ietf.org/html/rfc2616#section-14.21

Attached patch permits non-date values for "Expires", leaving them as
strings (preferable, as such responses can be transparently forwarded
to other clients). The staleness of a response could be determined
quite crudely, e.g.

(define (response-stale? r)
  (let ((expires (response-expires r)))
    (and expires
         (or (not (date? expires)) ;; Indicates already expired.
             (time<=? (date->time-utc expires)
                      (current-time))))))

This approach completely ignores the recommended way of determining
whether a response has expired.  See section 13.2.4 of the RFC for
calculations involving various factors such as the time that a request
was sent, "Cache-Control" directives, etc.


Regards

Daniel

[0001-Permit-non-date-values-for-Expires-header.patch (text/x-patch, attachment)]

Previous Next

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