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

Previous Next

Full log

Message #11 received at 10147 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Hartwig <mandyke <at> gmail.com>
To: Andy Wingo <wingo <at> pobox.com>
Cc: "R. P. Dillon" <rpdillon <at> gmail.com>, guile-user <at> gnu.org,
	10147 <at> debbugs.gnu.org
Subject: Re: bug#10147: HTTP "Expires" header should handle non-date values
Date: Thu, 22 Dec 2011 12:28:01 +0800

On 22 December 2011 10:51, Andy Wingo <wingo <at> pobox.com> wrote:
>
> On Sun 27 Nov 2011 05:39, Daniel Hartwig <mandyke <at> 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...
>

... especially given that players like Google are using "-1" ;-)

> ... Wouldn't it
> be better to keep the expires header as a date?  Would any date in the
> past work fine?
>

That is what I initially considered.  A great solution because it
requires no changes to existing code which would be expecting a date
value.  I think any date would do, ideally it would match the value of
the Date header, but the current parsing code does not allow for
access to it.  I considered using a single, well defined value for
date-in-the-past (Unix epoch).

The *only* concern I had with this approach is wrt implementing a
cache/proxy.  My idea was that by storing the non-date values as a
string you can store/forward these unmodified and still check for the
"already expired" condition.

Admitedly this is a very minor concern, as there is no change in
semantics at the protocol level -- both approaches result in the
client understanding that the content is already expired.

I think what I came up with was a solution in need of a problem
(which should be solved more generally across the whole module
any way).


> Would it be best to allow some special cases like "0" or "-1" instead?
>

Not sure precisely what you mean here.  Is it something like:

(or (false-if-exception (parse-date str))
    (and (memq str '("0" "-1")) str)
    date-in-the-past)

?

> I'm just trying to limit the damage here :)  WDYT?
>

I am certainly in favour of keeping the value as a date to achieve
this aim.

Previous Next

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