On Wed 21 Dec 2011 23:28, Daniel Hartwig <mand...@gmail.com> writes:
> On 22 December 2011 10:51, Andy Wingo <wi...@pobox.com> wrote:
>>
>> On Sun 27 Nov 2011 05:39, Daniel Hartwig <mand...@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/
