Title: mod_cache behaviour in Apache 2.0.44
One more question about mod_cache :
 
How does it handle conditionnal requests ? Because, in mod_cache.c, in the cache_url_handler function, it checks if info->etag and info->lastmods are set and, if not, make a nonconditionnal request to the end server.
 
BUT, it seems that info->lastmods and info->etag are never set, because they are not saved on the disk through this structure (see mod_disk_cache's write_headers function), but they are saved as other headers. So, my questions are :
 
* Is it a bug or just not yet implemented ?
* If it's a bug, should we take the ETag and the Last-Modified info directly from the cached headers with :
   lastmods = apr_table_get(r->headers_out, "Last-Modified");
 
Thanks for helping me with that ! And by the way, if you could look at my preceding mail... ;-)
 
Thomas.
 
-----Message d'origine-----
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..."

Reply via email to