GNU bug report logs -
#10147
HTTP "Expires" header should handle non-date values
Previous Next
Reported by: Daniel Hartwig <mandyke <at> gmail.com>
Date: Sun, 27 Nov 2011 10:42:02 UTC
Severity: normal
Tags: patch
Found in version 2.0.3
Done: Andy Wingo <wingo <at> pobox.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Mon, 09 Jan 2012 23:36:44 +0100
with message-id <87mx9w4i6b.fsf <at> pobox.com>
and subject line Re: bug#10147: HTTP "Expires" header should handle non-date values
has caused the debbugs.gnu.org bug report #10147,
regarding HTTP "Expires" header should handle non-date values
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> 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)]
[Message part 3 (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)]
[Message part 5 (message/rfc822, inline)]
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/
This bug report was last modified 13 years and 187 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.