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

Previous Next

Package: guile;

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


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

From: Andy Wingo <wingo <at> pobox.com>
To: Daniel Hartwig <mandyke <at> gmail.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 07:35:24 -0500
On Wed 21 Dec 2011 23:28, Daniel Hartwig <mandyke <at> gmail.com> writes:

> 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:
>>
>>>    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").
>>
>> But, pragmatism may rule, here...
>
> ... especially given that players like Google are using "-1" ;-)

Yes, indeed.

>> ... 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.  I considered using a single,
> well defined value for date-in-the-past (Unix epoch).

I think I would prefer this.  It makes user code easier, and with more
of a chance of being correct.  I think that Mozilla at least used to use
the beginnning of the epoch as this date.

>> 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)

More like:

  (if (member str '("0" "-1"))
      date-in-the-past
      (parse-date str))

Then we can wait and see -- if only these two values are out there, then
we are good, and we keep the "validating" characteristic of our date
parser.  Otherwise we can fall back to the false-if-exception dance if
someone submits a bug report.

WDYT?  Want to send another patch? :-)

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.