PATCH 19824 -- enhancement to mod_expires

[Jeffrey Friedl <jf...@regex.info>]

I've submitted a small patch that enhances mod_expires to allow older files
to be given a different expires cookie than newer files.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41963

The common case where this is useful is to give image/js/css files older
than a few hours/days a long expires time so that they're cached, while
giving a very short or nonexistent expires time to just-written files so
that they may continue to be tweaked. Once the tweaking settles down and
the file remains unchanged long enough, it gets the long expire time.

This patch manifests itself in the configuration file by extending the
timespan arguments of ExpiresByType and ExpiresDefault to allow the form

   aged <timespan> then <timespan> [else <timespan>]

For example, currently (prior to this patch), one might use

   ExpiresByType image/jpeg "10 years"

so that images are cached essentially forever, but this means that they can
not reasonably be updated in place. However, with this patch, you might use

   ExpiresByType image/jpeg "aged 2 days  THEN  10 years  ELSE  1 hour"

to allow for some initial tweaking.


Is there any chance that a change like this could be accepted?

Thanks,
        Jeffrey
--------------------------------------------------------------------------
Jeffrey Friedl           Kyoto, Japan              http://regex.info/blog/

Re: PATCH 19824 -- enhancement to mod_expires

[Ruediger Pluem <rp...@apache.org>]

On 04/01/2007 11:24 AM, Niklas Edmundsson wrote:
> On Sat, 31 Mar 2007, Jeffrey Friedl wrote:
> 
>> so that images are cached essentially forever, but this means that
>> they can
>> not reasonably be updated in place. However, with this patch, you
>> might use
>>
>>   ExpiresByType image/jpeg "aged 2 days  THEN  10 years  ELSE  1 hour"
>>
>> to allow for some initial tweaking.
> 
> 
> I think it would make more sense to use the same behaviour as mod_cache
> instead of having hard-coded expire-times when it comes to entities
> which has a last-modified header, ie newly modified entities gets a low
> expire while stuff not changed for a while gets a high expire.

+1. For reference see http://httpd.apache.org/docs/2.2/en/mod/mod_cache.html#cachelastmodifiedfactor.
I may be off track here since we have no cache here, but it may be a good idea to add a Warning header
with a Warning 113 in the cases described in RFC 2616 14.46 (see also 13.2.2 and 13.2.4) as we would
have a heuristic expiration time here.

Regards

Rüdiger

Re: PATCH 19824 -- enhancement to mod_expires

[Niklas Edmundsson <ni...@acc.umu.se>]

On Sat, 31 Mar 2007, Jeffrey Friedl wrote:

> so that images are cached essentially forever, but this means that they can
> not reasonably be updated in place. However, with this patch, you might use
>
>   ExpiresByType image/jpeg "aged 2 days  THEN  10 years  ELSE  1 hour"
>
> to allow for some initial tweaking.

I think it would make more sense to use the same behaviour as 
mod_cache instead of having hard-coded expire-times when it comes to 
entities which has a last-modified header, ie newly modified entities 
gets a low expire while stuff not changed for a while gets a high 
expire.

/Nikke
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se      |     nikke@acc.umu.se
---------------------------------------------------------------------------
  Where will YOU be when your laxative starts working?
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=