On Fri, 2002-10-11 at 16:04, Paul J. Reder wrote: > I have run into a problem where the cache code randomly decides that a > cached entry is stale or that the last modified date is some time in > the future. I tracked it back to the ap_cache_check_freshness code > which does a lot of checking of dates. > > Some of this date checking code compares and assigns uncast numeric values > (such as -1) and the output of atoi() to the apr_time_t values (which are > long longs). The debugger showed me that only the bottom half of the > apr_time_t was being updated/compared. > > I would like to fix the code in the following ways (if there are no > objections): > 1) Replace the assignments/comparisons of 0 with APR_DATE_BAD > 2) Have someone create a "#define APR_DATE_UNASSIGNED ((apr_time_t)-1)" > value in apr_date.h. > 3) Replace the assignments/comparisons of -1 with APR_DATE_UNASSIGNED > 4) Replace the atoi() calls with calls to apr_atoi64().
At first glance, I think there's an even more fundamental problem: the code in ap_cache_check_freshness() appears to be mixing times measured in microseconds (the result of ap_cache_current_age()) with times measured in seconds (everything that it gets from the HTTP header). Brian
