Hi Daniel, So sorry for the delay.
On Sun 27 Nov 2011 05:39, Daniel Hartwig <mand...@gmail.com> writes: > 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 But that's right after saying The format is an absolute date and time as defined by HTTP-date in section 3.3.1; it MUST be in RFC 1123 date format: Expires = "Expires" ":" HTTP-date But, pragmatism may rule, here... > 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)))))) Let us assume that it is a good idea to include this hack. Wouldn't it be better to keep the expires header as a date? Would any date in the past work fine? Would it be best to allow some special cases like "0" or "-1" instead? I'm just trying to limit the damage here :) WDYT? Andy -- http://wingolog.org/
