Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
[EMAIL PROTECTED] wrote: rederpj 2003/09/12 12:28:47 Modified:.CHANGES modules/experimental mod_cache.c Log: This fixes the cache code so that responses can be cached if they have an Expires header but no Etag or Last-Modified headers. PR 23130. Submitted by: [EMAIL PROTECTED] Reviewed by: Paul J. Reder Index: CHANGES === RCS file: /home/cvs/httpd-2.0/CHANGES,v retrieving revision 1.1271 retrieving revision 1.1272 diff -u -r1.1271 -r1.1272 --- CHANGES 11 Sep 2003 18:24:25 - 1.1271 +++ CHANGES 12 Sep 2003 19:28:46 - 1.1272 @@ -2,6 +2,12 @@ [Remove entries to the current 2.0 section below, when backported] + *) This fixes the cache code so that responses can be cached + if they have an Expires header but no Etag or Last-Modified + headers. PR 23130. + [Submitted by: [EMAIL PROTECTED]] + [Reviewed by: Paul J. Reder] This should be *) This fixes the cache code so that responses can be cached if they have an Expires header but no Etag or Last-Modified headers. PR 23130. [[EMAIL PROTECTED]] unless you had to modify the code, in which case your name goes inside [] along with the other person's info with no distinguishing between the submitter and the reviewer. Also, it is nice to see a real name when known.
RE: cvs commit: httpd-2.0/modules/experimental mod_cache.c
Nice catch Paul.
Bill
rederpj 2002/12/17 07:29:02
Modified:.CHANGES
modules/experimental mod_cache.c
Log:
mod_cache: Fix PR 15113, a core dump in cache_in_filter when
a redirect occurs. The code was passing a format string and
integer to apr_pstrcat. Changed to apr_psprintf. [Paul J. Reder]
Revision ChangesPath
1.1012+5 -0 httpd-2.0/CHANGES
Index: CHANGES
===
RCS file: /home/cvs/httpd-2.0/CHANGES,v
retrieving revision 1.1011
retrieving revision 1.1012
diff -u -r1.1011 -r1.1012
--- CHANGES 15 Dec 2002 16:37:18 - 1.1011
+++ CHANGES 17 Dec 2002 15:29:01 - 1.1012
@@ -2,6 +2,11 @@
[Remove entries to the current 2.0 section below, when backported]
+ *) mod_cache: Fix PR 15113, a core dump in cache_in_filter when
+ a redirect occurs. The code was passing a format string and
+ integer to apr_pstrcat. Changed to apr_psprintf.
+ [Paul J. Reder]
+
*) mod_mime: Workaround to prevent a segfault if r-filename=NULL
[Brian Pane]
1.70 +2 -2 httpd-2.0/modules/experimental/mod_cache.c
Index: mod_cache.c
===
RCS file: /home/cvs/httpd-2.0/modules/experimental/mod_cache.c,v
retrieving revision 1.69
retrieving revision 1.70
diff -u -r1.69 -r1.70
--- mod_cache.c 11 Dec 2002 22:31:28 - 1.69
+++ mod_cache.c 17 Dec 2002 15:29:02 - 1.70
@@ -532,11 +532,11 @@
* We include 304 Not Modified here too as this is the
origin server
* telling us to serve the cached copy.
*/
- reason = apr_pstrcat(p, Response status %d, r-status);
+ reason = apr_psprintf(p, Response status %d, r-status);
}
else if (exps != NULL exp == APR_DATE_BAD) {
/* if a broken Expires header is present, don't cache it */
-reason = apr_pstrcat(p, Broken expires header %s, exp);
+reason = apr_psprintf(p, Broken expires header %s, exp);
}
else if (r-args exps == NULL) {
/* if query string present but no expiration time,
don't cache it
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
On Tue, Dec 17, 2002 at 05:10:05PM -, Bill Stoddard wrote:
Fix PR 15113, a core dump in cache_in_filter when
a redirect occurs. The code was passing a format string and
integer to apr_pstrcat. Changed to apr_psprintf. [Paul J. Reder]
PR: 15113
...
else if (exps != NULL exp == APR_DATE_BAD) {
/* if a broken Expires header is present, don't cache it */
-reason = apr_pstrcat(p, Broken expires header %s, exp);
+reason = apr_psprintf(p, Broken expires header %s, exp);
Still not right - 'exp' is an apr_time_t, you mean 'exps' I guess?
mod_cache.c: In function `cache_in_filter':
mod_cache.c:543: warning: format argument is not a pointer (arg 3)
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
On Tue, 17 Dec 2002, Joe Orton wrote:
On Tue, Dec 17, 2002 at 05:10:05PM -, Bill Stoddard wrote:
else if (exps != NULL exp == APR_DATE_BAD) {
/* if a broken Expires header is present, don't cache it */
-reason = apr_pstrcat(p, Broken expires header %s, exp);
+reason = apr_psprintf(p, Broken expires header %s, exp);
Still not right - 'exp' is an apr_time_t, you mean 'exps' I guess?
mod_cache.c: In function `cache_in_filter':
mod_cache.c:543: warning: format argument is not a pointer (arg 3)
Oooh, yowtch... good call. I wasn't even looking at that part.
--Cliff
RE: cvs commit: httpd-2.0/modules/experimental mod_cache.c
Thanks! Fixing in 2.0 and 2.1...
Bill
On Tue, Dec 17, 2002 at 05:10:05PM -, Bill Stoddard wrote:
Fix PR 15113, a core dump in cache_in_filter when
a redirect occurs. The code was passing a format string and
integer to apr_pstrcat. Changed to apr_psprintf. [Paul J. Reder]
PR: 15113
...
else if (exps != NULL exp == APR_DATE_BAD) {
/* if a broken Expires header is present, don't cache it */
-reason = apr_pstrcat(p, Broken expires header %s, exp);
+reason = apr_psprintf(p, Broken expires header %s, exp);
Still not right - 'exp' is an apr_time_t, you mean 'exps' I guess?
mod_cache.c: In function `cache_in_filter':
mod_cache.c:543: warning: format argument is not a pointer (arg 3)
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
Yup, the coredump happened in the first call with the %d. I just
patched this second call without looking at the exp parm, then failed
to notice the warning... *sigh* must be near Christmas vacation
when it takes three passes to get something like this right... ;)
Cliff Woolley wrote:
On Tue, 17 Dec 2002, Joe Orton wrote:
On Tue, Dec 17, 2002 at 05:10:05PM -, Bill Stoddard wrote:
else if (exps != NULL exp == APR_DATE_BAD) {
/* if a broken Expires header is present, don't cache it */
-reason = apr_pstrcat(p, Broken expires header %s, exp);
+reason = apr_psprintf(p, Broken expires header %s, exp);
Still not right - 'exp' is an apr_time_t, you mean 'exps' I guess?
mod_cache.c: In function `cache_in_filter':
mod_cache.c:543: warning: format argument is not a pointer (arg 3)
Oooh, yowtch... good call. I wasn't even looking at that part.
--Cliff
--
Paul J. Reder
---
The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure.
-- Albert Einstein
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
At 02:23 PM 12/17/2002, Paul J. Reder wrote:
Yup, the coredump happened in the first call with the %d. I just
patched this second call without looking at the exp parm, then
failed to notice the warning... *sigh* must be near Christmas
vacation when it takes three passes to get something like this
right... ;)
Any reason not to just use apr_pstrcat(p, Broken expires header ,
exps) and save the overhead of the psprintf?
Cliff Woolley wrote:
On Tue, 17 Dec 2002, Joe Orton wrote:
On Tue, Dec 17, 2002 at 05:10:05PM -, Bill Stoddard wrote:
else if (exps != NULL exp == APR_DATE_BAD) {
/* if a broken Expires header is present, don't
cache it */
-reason = apr_pstrcat(p, Broken expires header
%s, exp);
+reason = apr_psprintf(p, Broken expires header
%s, exp);
Still not right - 'exp' is an apr_time_t, you mean 'exps' I guess?
mod_cache.c: In function `cache_in_filter':
mod_cache.c:543: warning: format argument is not a pointer (arg 3)
Oooh, yowtch... good call. I wasn't even looking at that part.
--
Greg Marr
[EMAIL PROTECTED]
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
On Tue, 17 Dec 2002, Greg Marr wrote: Any reason not to just use apr_pstrcat(p, Broken expires header , exps) and save the overhead of the psprintf? None that I know of. It's not the main-line case, so it's not the most critical thing in the world performance-wise, but I suppose it couldn't hurt. Anyway, wouldn't it be: apr_pstrcat(p, Broken expires header , exps, NULL); I was pretty sure you need the NULL there for pstrcat. --Cliff
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
[EMAIL PROTECTED] writes: ianh02/01/30 10:05:26 Modified:modules/experimental mod_cache.c Log: out damn warnings out Index: mod_cache.c === RCS file: /home/cvs/httpd-2.0/modules/experimental/mod_cache.c,v retrieving revision 1.19 retrieving revision 1.20 diff -u -r1.19 -r1.20 --- mod_cache.c 25 Jan 2002 20:09:33 - 1.19 +++ mod_cache.c 30 Jan 2002 18:05:26 - 1.20 @@ -63,6 +63,10 @@ module AP_MODULE_DECLARE_DATA cache_module; +int ap_url_cache_handler(request_rec *r); +int ap_cache_out_filter(ap_filter_t *f, apr_bucket_brigade *bb); +int ap_cache_conditional_filter(ap_filter_t *f, apr_bucket_brigade *in); +int ap_cache_in_filter(ap_filter_t *f, apr_bucket_brigade *in); I started to work on the warnings too, but I don't know what the real fix is. It seems to me that exactly one of the following has to be done: 1) make them static (and for extra credit drop the ap_ prefix) 2) put the declarations in a header file -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
Jeff Trawick wrote: [EMAIL PROTECTED] writes: ianh02/01/30 10:05:26 Modified:modules/experimental mod_cache.c Log: out damn warnings out Index: mod_cache.c === RCS file: /home/cvs/httpd-2.0/modules/experimental/mod_cache.c,v retrieving revision 1.19 retrieving revision 1.20 diff -u -r1.19 -r1.20 --- mod_cache.c 25 Jan 2002 20:09:33 - 1.19 +++ mod_cache.c 30 Jan 2002 18:05:26 - 1.20 @@ -63,6 +63,10 @@ module AP_MODULE_DECLARE_DATA cache_module; +int ap_url_cache_handler(request_rec *r); +int ap_cache_out_filter(ap_filter_t *f, apr_bucket_brigade *bb); +int ap_cache_conditional_filter(ap_filter_t *f, apr_bucket_brigade *in); +int ap_cache_in_filter(ap_filter_t *f, apr_bucket_brigade *in); I started to work on the warnings too, but I don't know what the real fix is. It seems to me that exactly one of the following has to be done: 1) make them static (and for extra credit drop the ap_ prefix) 2) put the declarations in a header file yep.. your right.. these should be static. fix it in a second.
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
At 06:19 PM 09/03/2001, Graham Leggett wrote: Greg Marr wrote: How exactly do you use Cache-Control directives so that the content that is cached is before includes are processed, and that when it is retrieved from the cache, the includes are processed? It just doesn't work that way. In this case you have to put the includes before the cache. mod_cache and mod_include should have no knowledge of each other. Exactly. They shouldn't care in which order they are run, that should be up to the admin. You're saying the opposite, that mod_cache should only be able to run after mod_include. mod_cache is interested in content going to the browser. You're interested in having mod_cache only interested in content going to the browser. There's a difference. There are already two caches in the loop (a transparent ISP cache, and the browser cache) so if mod_include doesn't generate proper Cache-Control: headers then mod_includes is broken already without any help from mod_cache. This has absolutely nothing to do with using mod_cache to cache the page just before it is processed by mod_include, and processing the page retrieved from the cache using mod_include. I don't see any reason why mod_cache should interfere with mod_include (or vice versa). Apparently you do. mod_cache only cares about what is spat out at the end of the filter chain Why should it be restricted like that? That makes it less useful. One of the fundamental design points about mod_cache was to separate it from all other modules (specifically mod_proxy). Tying mod_cache behaviour to mod_include (or any other module) is a step backwards in the design. So why are you saying it should be done that way? It should be able to be placed at any point in the filter chain. Requiring it to come after mod_whatever is tying its behavior to mod_whatever, saying that mod_whatever must process the file before it is cached. -- Greg Marr [EMAIL PROTECTED] We thought you were dead. I was, but I'm better now. - Sheridan, The Summoning
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
From: Bill Stoddard [EMAIL PROTECTED] Sent: Tuesday, September 04, 2001 10:02 AM I agree with this. Our current AP_FTYPE_* classifications is not granular enough to support this but that is easily fixed. Patch on the way... Err or not. Jeff convinced me that it was premature to add additional AP_FTYPES. For now, everything FTYPE_HEADERS (cache, content encoding, charset translations, et. al.) should be an FTYPE_CONTENT filter. That works for me ... I'd agree, if this is what it looks like; Bill A transfer encoding isn't a byterange or chunking output. It's a compression scheme, and that we _want_ to cache, to avoid the cpu overhead. Handler (e.g. Core/autoindex/mod_webapp etc) FTYPE_CONTENT Includes and other Filters V Charset Translation (Transform to Client's preference) V Content Encoding (gz) (Body - large packets - higher compression) END FTYPE_CONTENT X cache here V Byterange V I forgot to insert about here... Transfer-Encoding (gz) (Really unsupported today by any clients per Kiley) V Chunking V Headers V SSL Crypto V Network I/O
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
just to add my 2c to the picture. I dont see why the cache-filter could not live anywhere in the filter chain it could sit just after the handler (where it could cache a report generator) which would then feed into php/include it could sit after php/include and possibly after the gzip/byte ranges as well. the thing it needs to do, (which I haven't seen yet) is address how it uniquely identifies what is the same request. Are you referring to the fact that a single URL may actually represent multiple views (and perhaps multiple cache entries)? I believe Graham's idea was to allow caching multiple views using the same URL. Searching the cache using a URL as key would return a collection of cache objects. cache_select_url() would negotiate across the collection to determine which object, if any, should be served. An alternate solution would be to cache content using complex search keys, rather than just the URL (i.e., don't return collections, only unique single cache objects). It needs to be cofigurable so that it could use the * incoming vhost+request (simple case) * the user agent * a cookie value (or part of) * any part of the incoming request header. so.. you might have something like SetOutputfilter CACHE INCLUDE GZ CACHECRITERIA REQ, UserAgent or SetOutputFilter INCLUDE GZ CACHE CACHECRITERIA REQ, Cookie: Foo+8 (last 8 bytes of Foo) We need a whole new class of configuration directives to control how cache search keys are built. For ESI (and other HTML tag driven caches) you would probably want to allow dynamically constructing a rule set that contains rules for building search keys. cache_select_url() would use the rule set as a guide for building sophisticated search keys using cookies, request parameters, etc. The rule set could be built at startup based on config directives or at runtime based on whatever runtime criterion you choose. Interesting stuff... Bill
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
Ryan Bloom wrote: But keeping it simple would essentially make the cache less useful. If I request a pdf file using three different browsers, the server will most likely have three different copies of the same file. One with byteranges, one with chunks, and one with neither. This returns to the point about whether the cache should store data with the transfer encodings applied, or not. I think that the cache should store data *without* transfer encodings applied: Ie not chunked and not byteranged. This solves your problem. If we do need to do anything clever (AKA potentially confusing) like apply a gzip transfer encoding before caching content (or applying a gunzip filter if the opposite is true) it's done within the cache_storage.c code - thus keeping potentially confusing stuff out of the Apache filter stacks. Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... S/MIME Cryptographic Signature
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
Multiple filters in the chain for each classification can exist (ordering between classifications shouldn't matter...) This way you can have a URL handled by mod_include and mod_php (but the mod_include portion can't create PHP tags and vice versa since you can't guarantee when it will run in relation to the other). I have no clue how this relates to our code or how others sees this. This is my quick uninformed birds-eye view. Thoughts? This ordering seems to be a problem that we need to address. Definitely. One of the most requested features in the past has been stacked content handlers, and if we now say that we support stacked modules as long as they aren't content handlers, then a lot of people will wonder what the heck we are doing. There should be a way to specify ordering of the content handlers in the stack. -Rasmus
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
Justin Erenkrantz wrote:
handler---content-filter-cache-filter-transfer-filter-network
(default) (mod_include, (mod_cache) (mod_gz{ip}, (core)
mod_php) ^ mod_proxy,
| byte ranges)
can short-cut
handler and content-filters
Almost - mod_proxy is a handler, not a transfer filter (otherwise you
could never cache proxy requests):
Basically, there are three states of operation, answering the question
is this URL cached with the answers yes, no and maybe. The
mod_cache handler works out each state, and in each state, the
filter stack is set up to look like this:
o NO - a virgin URL
handler - content - CACHE_IN - transfer - core
(mod_cache (mod_include (mod_gzip,
mod_proxy mod_php) BYTERANGE)
mod_core)
o YES - a cached URL
handler - CACHE_OUT - transfer - core
o MAYBE - a stale URL
handler - content - CACHE_CONDITIONAL - CACHE_IN|CACHE_OUT -
transfer - core
To sum up, the cache is always first and last (last except for transfer
encodings) so ordering of content filters should not matter to
mod_cache.
Regards,
Graham
--
-
[EMAIL PROTECTED]There's a moon
over Bourbon Street
tonight...
S/MIME Cryptographic Signature
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
From: Graham Leggett [EMAIL PROTECTED] Sent: Monday, September 03, 2001 11:30 AM Ryan Bloom wrote: But keeping it simple would essentially make the cache less useful. If I request a pdf file using three different browsers, the server will most likely have three different copies of the same file. One with byteranges, one with chunks, and one with neither. This returns to the point about whether the cache should store data with the transfer encodings applied, or not. I think that the cache should store data *without* transfer encodings applied: Ie not chunked and not byteranged. This solves your problem. WFT?!? I've been letting this conversation slide (to avoid IO) but this is absurd. OF COURSE you don't apply transfer mechanics (e.g. byteranges, chunking etc) to a cache!!! They aren't reusable - they are likely meaningless to any other request. You will waste more time searching the cache than you save with occasional hits to it. A transfer encoding isn't a byterange or chunking output. It's a compression scheme, and that we _want_ to cache, to avoid the cpu overhead. Handler (e.g. Core/autoindex/mod_webapp etc) V Includes and other Filters V Charset Translation (Transform to Client's preference) V Content Encoding (gz) (Body - large packets - higher compression) V X cache here V Byterange V Chunking V Headers V SSL Crypto V Network I/O
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
From: Justin Erenkrantz [EMAIL PROTECTED]
Sent: Monday, September 03, 2001 5:39 PM
I'll jump in here now that I have an idea what you are talking
about. I think our filter classifications can be:
handler---content-filter-cache-filter-transfer-filter-network
(default) (mod_include, (mod_cache) (mod_gz{ip}, (core)
mod_php) ^ mod_proxy,
| byte ranges)
can short-cut
handler and content-filters
And we don't proxy proxies??? mod_proxy (viewed as a handler, or origin
of a request response body) is most definately cached. gzip can be cached.
Your 'transfer filter' category is _way_ to broad.
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
On Monday 03 September 2001 15:42, Rasmus Lerdorf wrote: Multiple filters in the chain for each classification can exist (ordering between classifications shouldn't matter...) This way you can have a URL handled by mod_include and mod_php (but the mod_include portion can't create PHP tags and vice versa since you can't guarantee when it will run in relation to the other). I have no clue how this relates to our code or how others sees this. This is my quick uninformed birds-eye view. Thoughts? This ordering seems to be a problem that we need to address. Definitely. One of the most requested features in the past has been stacked content handlers, and if we now say that we support stacked modules as long as they aren't content handlers, then a lot of people will wonder what the heck we are doing. There should be a way to specify ordering of the content handlers in the stack. There is. In fact, there are TWO ways to configure this. The first way, is to do it in the config file. If you do: AddOutputFilter INCLUDES PHP Then mod_include will always be run before mod_php. the second way is for module authors to do this. Each module has an insert_filters phase. By ordering the insert_filters phase, you can order which filter is called when. If for some reason, the PHP developers always wanted to run before mod_include, then they should specify that the php insert_filters phase runs before the mod_include insert_filters phase. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
Bill Stoddard wrote: Yep, you definitely need CACHE_OUT to be a CONTENT filter in this case since INCLUDES is a CONTENT filter and you need INCLUDES to be run after CACHE_OUT. I disagree - includes is something that should be cached as it is a performance bottleneck. If mod_includes needs to bypass the cache then Cache-Control directives should be applied. If the user specifies cache this URL range it would be wrong to override the user's wishes and not cache something. Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... S/MIME Cryptographic Signature
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
Bill Stoddard wrote: I'm a bit fuzzy on how to run the GZIP filter from CACHE_IN but I assume something clean can be done. Detecting if the client supports unzip and conditionally installing GUNZIP is simple and should just work without resorting to anything unnatural. The cache_storage.c was designed to be the place where such optimisations happen. Data is passed to it as a brigade, so it should be relatively easy to pass that brigade through specific filters like GZIP (or GUNZIP) before handing the brigades to the caching subfilters. Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... S/MIME Cryptographic Signature
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
Ryan Bloom wrote: My own opinion is that the cache should be the last content filter run. Basically, it should probably be specified as the first HTTP_HEADER filter type. The core question is whether we store data in the cache with transfer encodings already applied. Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... S/MIME Cryptographic Signature
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
Greg Marr wrote: In Ian's particular case, that is incorrect. The value of his includes vary from request to request, so he needs the cache to be before the includes filter. This isn't necessary - simply use the Cache-Control directives correctly so that the includes content is not cached. Remember that there is already a cache (in the form of an ISP transparent cache) between the browser and server anyway (in most cases), mod_cache should behave exactly like a transparent cache would. You're saying that we should override the user's wishes and cache the page with the request-specific information instead of before these are added. No, I'm saying use the Cache-Control directives correctly exactly as a transparent proxy would. Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... S/MIME Cryptographic Signature
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
Graham Leggett [EMAIL PROTECTED] wrote: Greg Marr wrote: In Ian's particular case, that is incorrect. The value of his includes vary from request to request, so he needs the cache to be before the includes filter. This isn't necessary - simply use the Cache-Control directives correctly so that the includes content is not cached. How exactly do you use Cache-Control directives so that the content that is cached is before includes are processed, and that when it is retrieved from the cache, the includes are processed? It just doesn't work that way. In this case you have to put the includes before the cache. mod_cache should behave exactly like a transparent cache would. In your application, yes, not in the one in question. No, I'm saying use the Cache-Control directives correctly exactly as a transparent proxy would. That's not the desired behavior.
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
On Saturday 01 September 2001 11:20, Graham Leggett wrote: Ryan Bloom wrote: The core question is whether we store data in the cache with transfer encodings already applied. I would put it before the content encodings, but after the content filters. My reasoning is simple. Content encodings tend to be fast, but content filtering tends to be slow. Cache the slow stuff, ignore the fast stuff. But from a keep-it-simple point of view, if we make the cache the very last filter, and then make it behave exactly like a transparent cache, then we have a good chance that it will just work, because the HTTP protocol defines the correct behavior already and transparent caches are widely deployed. If we start moving it up and down the filter chain, we're likely to introduce some nasty what-if's that we have not encoutered before. But keeping it simple would essentially make the cache less useful. If I request a pdf file using three different browsers, the server will most likely have three different copies of the same file. One with byteranges, one with chunks, and one with neither. That is a waste of space in the server, and chunking and byterange are incredibly cheap operations with bucket brigades. We have very well defined locations for filters, and if somebody tries to modify the content after the start of the HTTP_HEADER_FILTER ftype begins, the cache will be the least of our problems. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
[EMAIL PROTECTED] wrote: Make CACHE_IN and CACHE_CONDITIONAL AP_FTYPE_CONTENT filters. Comtemplating making a new filter type, AP_FTYPE_CACHE. We need to run CACHE_IN immediately after the handlers are done and before we run the content through any filters. In the original design the cache should be run as the very first handler, and the very last filter. This means that the gzip filter (for example) should run before the cache filter, so that gzipped data ends up in the cache, thus to save space within the cache, and save processing power when delivering content to clients. Regards, Graham How do you handle things like byterange requests if CACHE_IN is a network filter? The byterange filter will filter out all but the range requested so the CACHE_IN filter will never see the full response. Ditto the output chunking filter. Also, there could be various content translation filters installed in the filter stack (ASCII -- EBCDIC, language translation, whatever. The list is indeterminate so we cannot reliably put code into CACHE_IN to detect these conditions and not cache. Bill
