[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#10147: HTTP "Expires" header should handle non-date values

From: Daniel Hartwig
Subject: Re: bug#10147: HTTP "Expires" header should handle non-date values
Date: Tue, 27 Dec 2011 23:49:00 +0800

On 22 December 2011 20:35, Andy Wingo <address@hidden> wrote:
>> 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.

A rough check against ~2600 sites scraped from shows only a
handful with other values.  These two:

"Mon, 12 Jul 1996 1:00:00 GMT"
                  ^ misses leading `0'
"Thu, 01 Jan 1970 00:00:00 +0000"
                           ^ should be `GMT'

The second (use of `+0000') was also encountered amongst other
date-valued headers in ~1% of pages sampled.  There might be a case
here for relaxing `parse-date' as I don't think these should be
handled specifically for "Expires" headers.

There were three more like:

"{ts '2011-12-27 08:12:22'}"

which only appeared for "Expires" headers.  They look something like
server directives which should have been transformed to legit
expiration dates but haven't been, due to misconfiguration.  In this
case I'd rather throw an error than parse it (wrongly) to

Given those points, I have attached a patch implementing the suggested
handling for "Expires" and will take a look at perhaps relaxing
parse-date (and others).  Anyone have ideas on that?


Attachment: 0001-permit-non-date-values-for-Expires-header.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]