Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (herse.apache.org: local policy)
In-Reply-To: <45AE85B6.20702@apache.org>
References: <45AB7A0E.5050409@hippo.nl> <45AE85B6.20702@apache.org>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <41B45A9D-183F-40DC-9342-4CA9E302D4BE@gbiv.com>
Cc: dev@httpd.apache.org,
 dev@apr.apache.org
Content-Transfer-Encoding: 7bit
From: "Roy T. Fielding" <fielding@gbiv.com>
Subject: Re: Mod_cache expires check
Date: Wed, 17 Jan 2007 14:23:12 -0800
To: Ruediger Pluem <rpluem@apache.org>

On Jan 17, 2007, at 12:23 PM, Ruediger Pluem wrote:
> On 01/15/2007 01:56 PM, Bart van der Schans wrote:
>> In r463496 the following check was added to mod_cache.c :
>>
>>     else if (exp != APR_DATE_BAD && exp < r->request_time)
>>     {
>>         /* if a Expires header is in the past, don't cache it */
>>         reason = "Expires header already expired, not cacheable";
>>     }
>>
>> This check fails to correctly identify the expires header "Thu, 01  
>> Jan
>> 1970 00:00:00 GMT". The apr_date_parse_http function(exps) returns
>> (apr_time_t)0 which is equal to APR_DATE_BAD, but it should  
>> recognize it
>> as an already expired header. Is there a way to distinct between
>> APR_DATE_BAD and the unix epoch? Or is that considered a bad date?
>
> I would say 0 is not a bad day. But if this is a bug it is an APR(- 
> util) bug.
> Thus I forward it to the apr dev list.

No, it is a bug in the expression.  A date is an unsigned value and any
error is specifically forced to 0 so that the comparison

    if (exp < r->request_time)

will be true if exp == APR_DATE_BAD (as is desired in this case).

....Roy