Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Date: Mon, 21 May 2007 21:02:05 +0200 (MEST)
From: Niklas Edmundsson <nikke@acc.umu.se>
To: dev@httpd.apache.org
Subject: Re: mod_cache: Don't update when req max-age=0?
In-Reply-To: <12262.84.233.182.145.1179760634.squirrel@www.sharp.fm>
Message-ID: <Pine.GSO.4.64.0705212041010.17769@kleopatra.acc.umu.se>
References: <Pine.GSO.4.64.0705211627320.5452@kleopatra.acc.umu.se>
 <12262.84.233.182.145.1179760634.squirrel@www.sharp.fm>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT

On Mon, 21 May 2007, Graham Leggett wrote:

>> Since max-age=0 requests can't be fulfilled without revalidating the
>> object they don't benefit from this header rewrite, and requests with
>> max-age!=0 that can benefit from the header rewrite won't be affected
>> by this change.
>>
>> Am I making sense? Have I missed something fundamental?
>
> At first glance, doing this I think will break RFC2616 compliance, and if
> it does break RFC compliance then I think it should not be default
> behaviour. However if it does solve a real problem for admins, then having
> a directive allowing the admin to enable this behaviour does make sense.

Why would it break RFC compliance? This request will never benefit of 
the headers being saved to disk, and the headers returned to the 
client should of course be those that resulted of the revalidation of 
the object. The only difference is that they aren't saved to disk too.

The only difference I can see is that you can't "probe" that the 
previous request was a max-age=0 by doing max-age!=0 request 
afterwards...

> Zooming out a little bit, this seems to fall into the category of "RFC
> violations that allow the cache to either hit the backend less, or hit the
> backend not at all, for the benefit of an admin who knows whet they are
> doing".
>
> A simple set of directives that allow an admin to break RFC compliance
> under certain circumstances in order to achieve certain goals does make
> sense.

Yup. CacheIgnoreCacheControl is one of those, we use it on the 
offloaders that only serves large files that we know doesn't need the 
RFC behaviour.

/Nikke
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se      |     nikke@acc.umu.se
---------------------------------------------------------------------------
  Sir, We are receiving 285,000 Hails. � Crusher
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=