On 09/20/2006 08:27 PM, Issac Goldstand wrote:
Graham Leggett wrote:
On Wed, September 20, 2006 5:27 pm, Brian Akins wrote:
unless 0 is a valid content-length, which it can be. Also, what about
when we are reading something in without a know C-L, for example from an
origin doing chunks?
Ruediger Pluem wrote:
On 09/20/2006 08:27 PM, Issac Goldstand wrote:
Graham Leggett wrote:
On Wed, September 20, 2006 5:27 pm, Brian Akins wrote:
unless 0 is a valid content-length, which it can be. Also, what about
when we are reading something in without a know C-L, for example from
On 09/20/2006 09:59 PM, Issac Goldstand wrote:
Ruediger Pluem wrote:
First of all I guess you mean: BEFORE the CACHE_SAVE filter :-).
Yes, there is a reason why we cannot do this: This would create a possible
DoS, because we have to
suck in the whole response first before actually
Ruediger Pluem wrote:
On 09/20/2006 09:59 PM, Issac Goldstand wrote:
Ruediger Pluem wrote:
First of all I guess you mean: BEFORE the CACHE_SAVE filter :-).
Yes, there is a reason why we cannot do this: This would create a possible
DoS, because we have to
suck in the whole response first
This differs from a content coding in that the transfer-coding is a
property of the message, not of the original entity.
Based on that, it seems to be ok. However, we'd have to remove strong
ETags as a side-effect if it was done (since strong ETags change when
entity headers
tor 2006-09-21 klockan 00:19 +0300 skrev Issac Goldstand:
The only really relevant line I saw (in a quick 15 minute review) is RFC
2616-3.6 (regarding transfer-encodings):
Transfer-coding values are used to indicate an encoding
transformation that has been, can be, or may need to be
On Sun, 17 Sep 2006, Graham Leggett wrote:
Niklas Edmundsson wrote:
However, I don't see how you can do a lockless design with multiple files
and an index that can do:
* Clients read from the cache as files are being cached.
* Only one session caches the same file.
* Header/Body updates.
*
On Mon, September 18, 2006 9:35 am, Niklas Edmundsson wrote:
The easiest way to deal with this might be to have a timeout, if the
body hasn't shown up in $timeout time then something went bad,
DECLINE, meaning that the cache layer thinks it should cache the file
and acts accordingly. You
Niklas Edmundsson wrote:
Extra tracking sounds unnecessary if you can do it in a way that
doesn't need it.
It's not extra it just adding some tracking. When an objects gets
cached log (sql, db, whatever) that /blah/foo/bar.html is cached as
/cache/x/y/something.meta. Then it's very easy
Graham Leggett wrote:
I have not seen inside the htcacheclean code, why is the code reading the
headers? In theory the cache should be purged based on last access time,
deleted as space is needed.
Everyone should be mounting cache directories noatime, unless they don't
care about
Brian Akins wrote:
Niklas Edmundsson wrote:
Extra tracking sounds unnecessary if you can do it in a way that
doesn't need it.
It's not extra it just adding some tracking. When an objects gets
cached log (sql, db, whatever) that /blah/foo/bar.html is cached as
Issac Goldstand wrote:
I can see how other tracking information (like how often the
cached entity is accessed, last access time, etc) would be useful,
Also, those statistics could be updated asynchronously by using a queue
so that statistics doesn't slow down a busy web server.
--
Brian
Brian Akins wrote:
Issac Goldstand wrote:
I can see how other tracking information (like how often the
cached entity is accessed, last access time, etc) would be useful,
albeit expensive to keep track of, but I don't understand this specific
example.
It's not expensive, as these
Brian Akins wrote:
Issac Goldstand wrote:
I can see how other tracking information (like how often the
cached entity is accessed, last access time, etc) would be useful,
Also, those statistics could be updated asynchronously by using a queue
so that statistics doesn't slow down a busy
Niklas Edmundsson wrote:
However, I don't see how you can do a lockless design with multiple
files and an index that can do:
* Clients read from the cache as files are being cached.
* Only one session caches the same file.
* Header/Body updates.
* No index/files out-of-sync issues. Ever.
Niklas Edmundsson wrote:
However, I don't see how you can do a lockless design with multiple
files and an index that can do:
* Clients read from the cache as files are being cached.
* Only one session caches the same file.
* Header/Body updates.
* No index/files out-of-sync issues. Ever.
or in the cache, it is very easy to purge
entries.
Extra tracking sounds unnecessary if you can do it in a way that
doesn't need it.
At Apachecon, I'll talk some about our version of mod_cache.
Unfortunately, I can't share code :( But I can tell you the separate
files way is not a performance
for the body cumbersome.
If you somehow track what entries or in the cache, it is very easy to
purge entries.
At Apachecon, I'll talk some about our version of mod_cache.
Unfortunately, I can't share code :( But I can tell you the separate
files way is not a performance or housekeeping issue
Niklas Edmundsson wrote:
If I remember correctly the code in 2.2.3 only does whole-file
revalidation,
No, it can have a stale handle that it makes fresh if it gets a 304.
--
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies
On Wed, 13 Sep 2006, Davi Arnaut wrote:
I'm working on this. You may want to check my proposal at
http://verdesmares.com/Apache/proposal.txt
Will it be possible to do away with one file for headers and one file
for body in mod_disk_cache with this scheme?
The thing is that I've been
Niklas Edmundsson wrote:
Will it be possible to do away with one file for headers and one file
for body in mod_disk_cache with this scheme?
This definitely has lots of advantages - however HTTP/1.1 requires that
it be possible to modify the headers on a cached entry independently of
the
Niklas Edmundsson wrote:
The stuff is used in production and seems stable, however I haven't had
any response to the first (trivial) patch sent so I don't know if
there's any interest in this.
Can you post the patch again? Also, if you attach it to a bugzilla
entry, it's less likely to get
...
Issac
Davi Arnaut wrote:
On 13/09/2006, at 16:29, Issac Goldstand wrote:
Hi all,
I've been hacking at mod_cache a bit, and was surprised to find that
part of the decision to serve previously cached content or not was being
made by the backend provider and not mod_cache; specifically
On Thu, 14 Sep 2006, Graham Leggett wrote:
Niklas Edmundsson wrote:
Will it be possible to do away with one file for headers and one file for
body in mod_disk_cache with this scheme?
This definitely has lots of advantages - however HTTP/1.1 requires that it be
possible to modify the
On 14/09/2006, at 04:24, Niklas Edmundsson wrote:
On Wed, 13 Sep 2006, Davi Arnaut wrote:
I'm working on this. You may want to check my proposal at http://
verdesmares.com/Apache/proposal.txt
Will it be possible to do away with one file for headers and one
file for body in mod_disk_cache
the headers on a cached entry
independently of the cached body. As long as this is catered for,
it should be fine.
This is not a top priority since actually there is no complete
support for it in mod_cache (partial responses and such), but it
would be nice to have it.
We could later easily
On Thu, September 14, 2006 1:42 pm, Davi Arnaut wrote:
This is not a top priority since actually there is no complete
support for it in mod_cache (partial responses and such), but it
would be nice to have it.
HTTP/1.1 compliance is mandatory for the cache. If it doesn't work now, it
needs
,
I've been hacking at mod_cache a bit, and was surprised to find
that
part of the decision to serve previously cached content or not
was being
made by the backend provider and not mod_cache; specifically, the
expiration date of the content seems to be checked by
mod_disk_cache (as
part
On Thu, 14 Sep 2006, Davi Arnaut wrote:
On 14/09/2006, at 04:24, Niklas Edmundsson wrote:
On Wed, 13 Sep 2006, Davi Arnaut wrote:
I'm working on this. You may want to check my proposal at
http://verdesmares.com/Apache/proposal.txt
Will it be possible to do away with one file for headers
On 14/09/2006, at 08:48, Graham Leggett wrote:
On Thu, September 14, 2006 1:42 pm, Davi Arnaut wrote:
This is not a top priority since actually there is no complete
support for it in mod_cache (partial responses and such), but it
would be nice to have it.
HTTP/1.1 compliance is mandatory
On 14/09/2006, at 09:06, Niklas Edmundsson wrote:
On Thu, 14 Sep 2006, Davi Arnaut wrote:
On 14/09/2006, at 04:24, Niklas Edmundsson wrote:
On Wed, 13 Sep 2006, Davi Arnaut wrote:
I'm working on this. You may want to check my proposal at http://
verdesmares.com/Apache/proposal.txt
Will
On Thu, September 14, 2006 2:07 pm, Davi Arnaut wrote:
The cache is required to send to the client the most up-to-date
response, it doesn't mean it must cache it.
As I recall once cached, if an entry is stale and is revalidated, the
headers coming back with the 304 Not Modified must replace
On 14/09/2006, at 09:21, Davi Arnaut wrote:
On 14/09/2006, at 09:06, Niklas Edmundsson wrote:
On Thu, 14 Sep 2006, Davi Arnaut wrote:
On 14/09/2006, at 04:24, Niklas Edmundsson wrote:
On Wed, 13 Sep 2006, Davi Arnaut wrote:
I'm working on this. You may want to check my proposal at
On Thu, 14 Sep 2006, Davi Arnaut wrote:
I'm working on this. You may want to check my proposal at
http://verdesmares.com/Apache/proposal.txt
Will it be possible to do away with one file for headers and one file
for body in mod_disk_cache with this scheme?
Hi all,
I've been hacking at mod_cache a bit, and was surprised to find that
part of the decision to serve previously cached content or not was being
made by the backend provider and not mod_cache; specifically, the
expiration date of the content seems to be checked by mod_disk_cache (as
part
On 13/09/2006, at 16:29, Issac Goldstand wrote:
Hi all,
I've been hacking at mod_cache a bit, and was surprised to find that
part of the decision to serve previously cached content or not was
being
made by the backend provider and not mod_cache; specifically, the
expiration date
Can someone of our RFC experts please have a look at PR 35247
(http://issues.apache.org/bugzilla/show_bug.cgi?id=35247)?
Questions that remain are:
1. Does the current behaviour of mod_cache really violate RFC2616?
2. If yes, does the proposed patch fix this violation?
Regards
Rüdiger
On 05/25/2006 07:56 AM, Ruediger Pluem wrote:
During my analysis of PR39643
(http://issues.apache.org/bugzilla/show_bug.cgi?id=39643)
I found out that mod_cache and mod_filter do not work together correctly. In
fact mod_filter
crashes with a segfault if the content is delivered from
*before*
ap_invoke_handler. Although we call ap_run_insert_filter in the mod_cache
quick handler we do *not* initialize the filters there.
Which begs the question: why are we attaching output filters to mod_cache?
1. In mod_filter do a sanity check if the filter context has been
initialized
On 05/25/2006 09:02 AM, Nick Kew wrote:
On Thursday 25 May 2006 06:56, Ruediger Pluem wrote:
Which begs the question: why are we attaching output filters to mod_cache?
Because some module might offer a protocol or connection filter that should be
also run on cached content. e.g
During my analysis of PR39643
(http://issues.apache.org/bugzilla/show_bug.cgi?id=39643)
I found out that mod_cache and mod_filter do not work together correctly. In
fact mod_filter
crashes with a segfault if the content is delivered from the cache.
The segfault is caused by line 366
Not wanting to stir the huge pot o' stuff that is going on here, but
what are the thoughts of renaming mod_cache to mod_http_cache?
mod_cache is http specific. This would follow the general ide that
mod_proxy uses.
I am not suggesting changing any functionality at this time, simply
renaming
Brian Akins wrote:
Not wanting to stir the huge pot o' stuff that is going on here, but
what are the thoughts of renaming mod_cache to mod_http_cache? mod_cache
is http specific. This would follow the general ide that mod_proxy uses.
I am not suggesting changing any functionality
Brian Akins wrote:
Not wanting to stir the huge pot o' stuff that is going on here, but
what are the thoughts of renaming mod_cache to mod_http_cache? mod_cache
is http specific. This would follow the general ide that mod_proxy uses.
This is a good idea, but thinking about this for a bit
of the issues in the current mod_cache.
--
Brian Akins
Lead Systems Engineer
CNN Internet Technologies
Graham Leggett wrote:
Brian Akins wrote:
Not wanting to stir the huge pot o' stuff that is going on here, but
what are the thoughts of renaming mod_cache to mod_http_cache?
mod_cache is http specific. This would follow the general ide that
mod_proxy uses.
This is a good idea
On 5/3/06, Paul Querna [EMAIL PROTECTED] wrote:
I am okay with forcing people to wait for 2.4. Develop in trunk and/or
devel-branches freely. Don't worry about back porting it to the stable
branch, IMO.
+1. -- justin
This adds an optional function that one could use to get basic hit/miss
stats from mod_cache. Right now it just does hit or miss, could pass an
HTTP status code for various status (stale, error, etc.).
Default function does nothing.
--
Brian Akins
Lead Systems Engineer
CNN Internet
I'm away from my build/test environment, but this is mostly to plant an
idea.
Basically it does this:
Upon successful storage of an object, it call the optional
ap_cache_storage_notify. a module, if it implements this function,
could then use the ap_cache_info function to get info about the
Greetings all,
I may finally have some time to work on some mod_cache issues that have
been nagging me. Mostly performance things. I really want to stop
maintaining my own version here, but to do that mod_cache needs to be
sped up a bit.
I'm setting up a dev environment now, so hopefully
Brian Akins wrote:
A short list I have (mostly mod_disk_cache):
-read_table and read_array seem slower than they should be
-thundering herd when a popular object expires
Thundering herd was one of the original design goals of the new cache
that was never fully followed through. With the
We tried to solve thundering herd problem wih cache-requester module
which I have not committed yet. It is currently available on source
forge.
I have not found enough time to work on it after summer of code was
over as I was busy with my thesis, internship. now I have just
relocated to calif
Can we have mod_cache (and its providers) log why it didn't serve an
object from cache in debug?
First entry I see when requesting an object I know is cached is:
[Tue Dec 06 13:53:55 2005] [debug] mod_cache.c(129): Adding CACHE_SAVE
filter for /cnn/1.gif
no reason why we chose not to serve
On 12/06/2005 07:55 PM, Brian Akins wrote:
Can we have mod_cache (and its providers) log why it didn't serve an
object from cache in debug?
First entry I see when requesting an object I know is cached is:
[Tue Dec 06 13:53:55 2005] [debug] mod_cache.c(129): Adding CACHE_SAVE
filter
Another one. Can we get a vote?
Sorry to be a pest, just don't want these to be forgotten.
Brian Akins wrote:
Here's a new patch that changes the option name to CacheVaryOverride and
does some of the stuff Justin recommened.
I propose that we fix this bug by documenting, very very loudly, that
using mod_cache simply breaks mod_authz_host. A Large warning in the
mod_cache documentation, the Caching User Guide, the output of configure
when mod_cache is enabled, and the error log when mod_cache is loaded is
what I'm
Colm MacCarthaigh wrote:
Moving mod_cache to being an ordinary handler, instead of a quick
handler has been brought up here before, and I don't think that's going
anywhere. I can't see a way to fix this problem :/
Let me demonstrate my lack of knowledge of the cache code:
Would
On Thu, Oct 06, 2005 at 02:00:35PM -0700, Paul Querna wrote:
No :) We'd have to have two handlers in order to do that, and it should
be noted that creating a non-quick handler for mod_cache is itself a
reasonable amount of effort.
No it isn't.
I should pay more attention.
Here
On Tue, Sep 27, 2005 at 10:55:17AM +0100, Colm MacCarthaigh wrote:
I've done up a test for mod_cache + mod_dir brokenness;
http://people.apache.org/~colm/cache-test.patch
I've added a virtualhost for mod_cache, because caching can easily
interfere with a lot of the other tests
On Tue, Sep 27, 2005 at 11:10:29AM +0100, Joe Orton wrote:
Is it vaguely right? And can I commit it?
Some nits but otherwise go ahead, great!
1. use VirtualHost mod_cache - the _default_: is not necessary AFAIK
2. use just need 'cache', 'disk_cache' for the requirements
Excellent, even
Parin Shah wrote:
I have fixed that memory leak problem. also added script to include
libcurl whenever this module is included.
I hope that it doesn't mean that libcurl is going to be a permanent
solution, when subrequests (with minor changes) could serve the same
purpose.
BTW: if subrequests
On Wed, Aug 24, 2005 at 09:18:54AM -0500, Parin Shah wrote:
I have fixed that memory leak problem. also added script to include
libcurl whenever this module is included.
I hope that it doesn't mean that libcurl is going to be a permanent
solution, when subrequests (with minor changes)
Colm MacCarthaigh wrote:
On Wed, Aug 24, 2005 at 09:18:54AM -0500, Parin Shah wrote:
I have fixed that memory leak problem. also added script to include
libcurl whenever this module is included.
I hope that it doesn't mean that libcurl is going to be a permanent
solution, when subrequests
Nick Kew wrote:
Alternatively, maybe someone could post an executive summary of the
problems and benefits of standardising on libcurl?
I'm pretty familiar with libcurl. Great library. Here are some issues
I have had:
- asynchronous uses select only.
- random crashes with openssl, normal
On 8/24/05, Colm MacCarthaigh [EMAIL PROTECTED] wrote:
On Wed, Aug 24, 2005 at 09:18:54AM -0500, Parin Shah wrote:
I have fixed that memory leak problem. also added script to include
libcurl whenever this module is included.
I hope that it doesn't mean that libcurl is going to be a
Brian Akins wrote:
Nick Kew wrote:
Alternatively, maybe someone could post an executive summary of the
problems and benefits of standardising on libcurl?
I'm pretty familiar with libcurl. Great library. Here are some issues
I have had:
- asynchronous uses select only.
FWIW, I will
Paul Querna wrote:
FWIW, I will be looking at adding support for EPoll and/or KQueue to the
curl_multi_* interface sometime soonish for 'work.
on the curl-dev list, I suggested just using libevent
(http://www.monkey.org/~provos/libevent/), because it already
encapsulates all that.
--
--On August 24, 2005 4:21:38 PM +0100 Nick Kew [EMAIL PROTECTED] wrote:
So, is it time we introduced a general-purpose apr_http_client?
I'd be prepared to offer my code as a startingpoint, but I'd rather
not take the driving seat for further development and documentation.
We already went down
With the talk of direction of Apache, I though I, as an end user and
developer, would offer my wish list for mod_cache. We have been using
squid for various things, but are now mostly using Apache plus our own
custom cache module. Our module has grown to support most of the cool
features
On Tue, Aug 23, 2005 at 08:42:48AM -0400, Brian Akins wrote:
Deterministic temp files to avoid thundering herd:
http://marc.theaimsgroup.com/?l=apache-httpd-devm=112430743432417w=2
Especially Colm's comments:
Content definitely should not be served from the cache after it has
expired
Content definitely should not be served from the cache after it has
expired imo. However I think an approach like;
if((now + interval) expired) {
if(!stat(tmpfile)) {
update_cache_from_backend();
}
}
ie revalidate the cache content after
Colm MacCarthaigh wrote:
To a large extent mod_cache_requester (which from inspection seems to be
much further along than I thought) will solve this problem :)
True. I still think we need deterministic temp files so that several
threads are not simultaneously trying to cache the same
Parin Shah wrote:
I am already working on it. I have also posted initial version of this module.
http://utdallas.edu/~parinshah/mod-c-requester.0.2.tar.gz
-Parin.
Cool. Very good start. Leaks memory like a sieve, but good start.
It would be cool if we could find a way to use Apache's
On Tue, Aug 23, 2005 at 10:18:37AM -0400, Brian Akins wrote:
I've been looking at this, and it's possibly the Syntax that put me off,
but it looks painful on the admin, and probably on the server too.
There's nothing in those examples that can't be achieved by making the
non-CacheEnable cache
Cool. Very good start. Leaks memory like a sieve, but good start.
ohh, I thought I was taking care of it. I mean, code frees the memory
when no longer needed except during the shutdown of server. anyway I
will go through the code again to check that. Also feel free to point
out the code
Parin Shah wrote:
ohh, I thought I was taking care of it. I mean, code frees the memory
when no longer needed except during the shutdown of server. anyway I
will go through the code again to check that. Also feel free to point
out the code which is causing memory leak problem.
I'll look
Colm MacCarthaigh wrote:
per-dir does not help in quick_handler.
No, but it is useful at the save stage.
True. This would probably be fine. I would like to see more flexible
url matching, ala squid. Perhaps a way so that modules can register
their own matching functions.
Example.
Parin Shah wrote:
Cool. Very good start. Leaks memory like a sieve, but good start.
ohh, I thought I was taking care of it. I mean, code frees the memory
when no longer needed except during the shutdown of server. anyway I
will go through the code again to check that. Also feel free to point
Bill Stoddard wrote:
I've not looked at your code so I can't make specific recommendations.
Just remember, code allocated with any of the apr_pool functions is
freed only when that pool is reclaimed (end of a request for a request
pool, shutdown of the server for pconf, etc.). mod_mem_cache
Brian Akins wrote:
Bill Stoddard wrote:
I've not looked at your code so I can't make specific recommendations.
Just remember, code allocated with any of the apr_pool functions is
freed only when that pool is reclaimed (end of a request for a request
pool, shutdown of the server for pconf,
Some pseudo match configs and code:
Just examples, maybe not useful or doable.
#only cache things in /stuff when request comes from localhost
CacheEnable disk client=127.0.0.1 path=/stuff
#disable cacheing from special host
CacheDisable client=10.1.1.1.10
#don't cache any ssl stuff
Brian Akins wrote:
Some pseudo match configs and code:
It looks like you want an extreme level of flexibility for making
caching decisions based on characteristics of the request. Why not
piggy-back on mod_rewrite, which already has an absurdly complex
matching capability.
As in
, it would be cool if it
were easy to add more %{VARIABLES} to mod_rewrite...
Who is currently working on the per-dir mod_cache stuff? I am willing
to help.
--
Brian Akins
Lead Systems Engineer
CNN Internet Technologies
ohh, I thought I was taking care of it. I mean, code frees the memory
when no longer needed except during the shutdown of server. anyway I
will go through the code again to check that. Also feel free to point
out the code which is causing memory leak problem.
I'll look through it as
ohh, I thought I was taking care of it. I mean, code frees the memory
when no longer needed except during the shutdown of server. anyway I
will go through the code again to check that. Also feel free to point
out the code which is causing memory leak problem.
I'll look through it as
Hi,
I have fixed that memory leak problem. also added script to include
libcurl whenever this module is included.
http://utdallas.edu/~parinshah/mod-c-requester.0.3.tar.gz
Thanks,
Parin.
On 8/23/05, Parin Shah [EMAIL PROTECTED] wrote:
ohh, I thought I was taking care of it. I mean, code
[EMAIL PROTECTED] wrote:
What sort of testing did you do in those few hours?
That's why I posted it, to get some more input.
If I could play devil's advocate for a moment... my concern would be that
you haven't considered certain scenarios that won't work with this patch.
Most of the
Here's a new patch that changes the option name to CacheVaryOverride and
does some of the stuff Justin recommened.
--
Brian Akins
Lead Systems Engineer
CNN Internet Technologies
diff -ru httpd-trunk.orig/modules/cache/cache_storage.c
httpd-trunk.new/modules/cache/cache_storage.c
---
--On August 18, 2005 9:55:57 AM -0400 Brian Akins [EMAIL PROTECTED]
wrote:
Why do we pass request_rec to recall_headers, but not to recall_body. We
also always pass r-pool. How horrible would it be if the prototype was
changed to:
apr_status_t (*recall_body) (cache_handle_t *h, request_rec
Justin Erenkrantz wrote:
I'd be fine with it matching store_body's prototype. (Which is what you
have.) -- justin
Here's a patch that does this.
--
Brian Akins
Lead Systems Engineer
CNN Internet Technologies
diff -ru httpd-trunk.orig/modules/cache/mod_cache.c
my original work[1] to enable
mod_cache to run as both a Quick Handler and a Normal Handler. We could
also invent a new handler, 'middle' handler, that runs after
map_to_storage, but before the rest of the hooks. (And hence, ran once
we have done directory blocks)
Is this is essentially
This patch allows one to override the values of some headers so that they
vary to the same value.
Config Example:
#all lines that have gzip set one variable
SetEnvIf Accept-Encoding gzip gzip=1
#browsers that have problems with gzip
BrowserMatch MSIE [1-3] gzip=0
BrowserMatch MSIE [1-5].*Mac
Akins, Brian wrote:
This patch allows one to override the values of some headers so that they
vary to the same value.
CacheOverrideHeader Accept-Encoding gzip
CacheOverrideHeader User-Agent gzip
Very useful looking. I suggest CacheVaryOverride as a much more clear
and precise name.
--On August 17, 2005 3:01:03 PM -0400 Akins, Brian
[EMAIL PROTECTED] wrote:
This patch allows one to override the values of some headers so that they
vary to the same value.
Config Example:
# all lines that have gzip set one variable
SetEnvIf Accept-Encoding gzip gzip=1
# browsers that have
Justin Erenkrantz wrote:
The concept is fine. (And as Joshua pointed out 'CacheVaryOverride'
would be a better name.)
I'm not attatched to the name. So that sounds good to me.
A few issues with the implementation (modulo style nits)...
This was all done in a few hours today, including
for mod_cache to be intimate with the details of
the request, and it's none of mod_cache's damned business where
the content of its cache comes from.
But on the other hand, adding a fixup to declare content that is
non-cacheable by the local apache instance is quite legitimate.
Bill
In a message dated 8/17/2005 2:01:41 PM Central Daylight Time,
[EMAIL PROTECTED] writes:
CacheOverrideHeader Accept-Encoding gzip CacheOverrideHeader User-Agent gzip
This would allow all browsers that send "Accept-Encoding: gzip" and do not match the BrowserMatches to be mapped to the same
On Mon, Aug 15, 2005 at 01:29:13PM +0100, Colm MacCarthaigh wrote:
My main reason is that I can't enable or disable caching on a
per-directory or per-file basis.
The quick handler runs well before any knowledge is available about the
backend (dir/file). The only thing you know is the URI
On Mon, Aug 15, 2005 at 09:55:34AM +0100, Colm MacCarthaigh wrote:
mod_cache configurability sucks big-time. CacheEnable adds yet another
location mapping scheme for administrators to deal with, but this scheme
lacks basic flexibility;
It can't reliably disable caching for a directory
On Tue, Aug 16, 2005 at 06:02:04PM -0700, Justin Erenkrantz wrote:
The quick handler runs well before any knowledge is available about the
backend (dir/file). The only thing you know is the URI path: unsurprisingly,
this is all that CacheEnable and CacheDisable can reasonably work with.
It's
301 - 400 of 732 matches
Mail list logo
