Hi Daniel,
Thanks very much for the thorough analysis!
On Tue 27 Dec 2011 16:49, Daniel Hartwig writes:
> 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 tha
On 22 December 2011 20:35, Andy Wingo 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
>
On 22 December 2011 10:51, Andy Wingo wrote:
>
> On Sun 27 Nov 2011 05:39, Daniel Hartwig 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
Hi Daniel,
So sorry for the delay.
On Sun 27 Nov 2011 05:39, Daniel Hartwig 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 i
On Wed 21 Dec 2011 23:28, Daniel Hartwig writes:
> On 22 December 2011 10:51, Andy Wingo wrote:
>>
>> On Sun 27 Nov 2011 05:39, Daniel Hartwig writes:
>>
>>> HTTP/1.1 clients and caches MUST treat other invalid date formats,
>>> especially including the value "0", as in the past (i.e., "a
