mod_cache behaviour in Apache 2.0.44

[CASTELLE Thomas <tc...@generali.fr>]

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:minfrin@sharp.fm]
Envoyé : vendredi 24 janvier 2003 08:04
À : dev@httpd.apache.org
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
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight..."