httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jus...@erenkrantz.com>
Subject Re: [PATCH] mod_disk cached fixed
Date Wed, 04 Aug 2004 20:58:31 GMT
--On Wednesday, August 4, 2004 4:52 PM -0400 Brian Akins 
<bakins@web.turner.com> wrote:

> Possible scenerio:
>
> Serving cached content:
>
> -  lookup uri in cache (via md5?).
> -  check varies - a list of headers to vary on
> - caculate new key (md5) based on uri and clients value of these headers
> - lookup new uri in cache
> - continue as normal
>
> Caching an object:
> -see if object has been cached before by looking up uri in cache
> -do the Vary's match?
>     -no, discard old entry(?) and create new uri entry
>     -yes, generate new key based on client values
> -continue as normal

I wouldn't discard the old entry, but store it as a variant to also cache. 
But, yes, a two-level scheme like this may make sense.

This allows us to cache the gzipped and non-gzipped versions - which is what 
we'd want.

> The thing that sucks is if you vary on User-Agent.  You wind up with a ton
> of entries per uri.  I cheated in another modules by "varying" on an
> environmental variable.  Kind of like this:
>
> BrowserMatch ".*MSIE [1-3]|MSIE [1-5].*Mac.*|^Mozilla/[1-4].*Nav" no-gzip
>
> and just "vary" on no-gzip (1 or 0), but this may be hard to do just using
> headers...

Note that BrowserMatch with regexp's is ridiculously expensive.  Minimizing 
the need for that would be goodness, I think.  -- justin

Mime
View raw message