De : CASTELLE Thomas [mailto:[EMAIL PROTECTED]]
Envoyé : vendredi 24 janvier 2003 12:46
À : [EMAIL PROTECTED]
Objet : mod_cache behaviour in Apache 2.0.44
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..."