Hi there !
I'm currently looking at mod_cache to see if it is enough RFC compliant to be used in production environment, and I pointed to something that seems a bug to me, maybe can you help :
in cache_util.c, in the ap_cache_check_freshness function,
shouldn't the test :
if ((-1 < smaxage && age < (smaxage - minfresh)) ||
(-1 < maxage && age < (maxage + maxstale - minfresh)) ||
(info->expire != APR_DATE_BAD && age < (apr_time_sec(info->expire - info->date) + maxstale - minfresh))) {
be instead :
if ((-1 < smaxage && age < (smaxage - minfresh)) ||
(-1 < maxage && age < (maxage + maxstale - minfresh)) {
if (info->expire != APR_DATE_BAD && age < (apr_time_sec(info->expire - info->date) + maxstale - minfresh)) {
so that maxage and smaxage could be taken in consideration ? Because when there is a Last-Modified header, info->expire has a value and then takes priority over max-age. And I think that Last-Modified shouldn't take priority over Cache-Control: max-age...
Thanks for looking at this !
Thomas.
-----Message d'origine-----
De : Graham Leggett [mailto:[EMAIL PROTECTED]]
Envoy� : vendredi 24 janvier 2003 08:04
� : [EMAIL PROTECTED]
Objet : Re: "Group" not working properly
Jeff Trawick wrote:
> As others mentioned, that big number has the same representation as 32-bit
> -1. I checked a couple of systems and gid_t is unsigned 32-bit there,
> and Apache treats the number as gid_t internally. The user can code that
> big unsigned number for group if they want to. Operationally, the right
> thing happens either way; there is no bug.
Is it possible to put a warning in there, because 4294967295 "looks wrong".
Regards,
Graham
--
-----------------------------------------
[EMAIL PROTECTED] "There's a moon
over Bourbon Street
tonight..."
