[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#10147: HTTP "Expires" header should handle non-date values
From: |
Daniel Hartwig |
Subject: |
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 <address@hidden> wrote:
>
> On Sun 27 Nov 2011 05:39, Daniel Hartwig <address@hidden> 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.