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
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
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
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
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
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
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
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
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
[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
> > 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
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
> 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. Bill > 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) > > 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
Greg Marr wrote: > >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. No - I am saying mod_cache should run after *everything*, not just mod_include. > 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. Look closer at mod_cache before saying this cannot be done. mod_cache uses a user configuration to determine what URL prefixes to cache, and which URL prefixes not to cache. If you want to cache stuff before mod_include, then configure those included URLs to be cached, and not the final URL. Problem solved without trying to fiddle with mod_cache in the filter stack. > >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. There are many filter chains in Apache. Each subrequest has it's own chain, and mod_cache could be at the end of these subchains (and will be if you configure your URLs correctly). This solves your problem. > 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_ is tying its behavior to mod_, saying > that mod_ must process the file before it is cached. No - all mod_cache says is that it goes last in a request chain, that's all. It neither knows about nor cares about other modules. 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
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... 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) > 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
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_ is tying its behavior to mod_, saying that mod_ 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
On Monday 03 September 2001 18:58, William A. Rowe, Jr. wrote: > From: "Ryan Bloom" <[EMAIL PROTECTED]> > Sent: Monday, September 03, 2001 8:03 PM > > > On Monday 03 September 2001 15:42, Rasmus Lerdorf wrote: > > > 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 > > Did you mean this? SetOutputFilter INCLUDES;PHP Yeah, I didn't lookup the syntax, just went from memory. Ryan > At this point, I'm strongly in favor of all usual mappings > (Add/SetOutputFilter) occuring in the mime_types phase. When the > insert_filters hook is invoked, your module can look at the filter stack, > and rearrange it however you like. Of course, others in that hook chain > could do the same, so it makes sense to only change what you absolutely > must. No, allowing random modules to re-order the filter chain is just asking for trouble, and it removes any hope of allowing the admin to order it correctly for their site. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
From: "Ryan Bloom" <[EMAIL PROTECTED]> Sent: Monday, September 03, 2001 8:03 PM > On Monday 03 September 2001 15:42, Rasmus Lerdorf wrote: > > 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 Did you mean this? SetOutputFilter INCLUDES;PHP If you used the syntax; AddOutputFilter INCLUDES shtml AddOutputFilter PHP php And request foo.shtml.php - it's shtml parsed, then php parsed. If you request foo.php.shtml - it's php parsed, then shtml parsed. > 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. At this point, I'm strongly in favor of all usual mappings (Add/SetOutputFilter) occuring in the mime_types phase. When the insert_filters hook is invoked, your module can look at the filter stack, and rearrange it however you like. Of course, others in that hook chain could do the same, so it makes sense to only change what you absolutely must. Bill
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
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
Ian Holsman wrote: > 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. Because it's pointless to cache something twice. The point behind mod_cache is to try and "walk the filter stack" as few times as possible, and over as shorter distances as possible. The only sane way of doing this is to cache as broadly as possible. Remember you can define the URL prefix that is to be cached and how - which in turn means that it theoretically possible to only cache subrequests and not cache the main request. But - you will be doing this because the user specifically configured their URLs like this, and not because the module tried to second guess what the user wanted to achieve. 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
Graham Leggett wrote:
> 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):
>
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.
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)
..Ian
(on a side note this would be a great way to implment Edge Side Includes
in 2.0 http://www.esi.org)
> 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
>
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
> 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
On Mon, Sep 03, 2001 at 06:30:54PM +0200, Graham Leggett wrote:
> I think that the cache should store data *without* transfer encodings
> applied: Ie not chunked and not byteranged. This solves your problem.
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
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.
-- justin
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
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. mod_cache is interested in content going to the browser. 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. Any Cache-Control headers generated by CGIs (or whatever) embedded in includes should already be combined intelligently into the final output result otherwise mod_include is broken now. > > mod_cache should behave exactly like a transparent cache would. > > In your application, yes, not in the one in question. I don't see any reason why mod_cache should interfere with mod_include (or vice versa). mod_cache only cares about what is spat out at the end of the filter chain - how that filter chain is constructed is not important to mod_cache (or any transparent cache or browser cache) at all. 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. Regards, Graham -- - [EMAIL PROTECTED]"There's a moon over Bourbon Street tonight..." S/MIME Cryptographic Signature
mod_include Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
Graham Leggett wrote: >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. > Yes, include processing is a performance bottleneck. But some of us are trying to fix that. :-) mod_include's slowness is due mostly to implementation details, rather than any fundamental architectural limitations. For example, it's not uncommon for mod_include to spend a third of its execution time setting environment variables that are never read. The two patches that I recently posted (one for the environment variable code, the other for the code that splits buckets if the buffered data is too large) should help streamline mod_include so that it spends most of its time doing what one would expect: scanning the content to look for SSI directives. In addition, Ian is working on improvements to the parser logic itself-- e.g., scanning every 5th character, rather than every character, when looking for a '
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
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
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. 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
On Saturday 01 September 2001 05:51, Graham Leggett wrote: > 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. 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. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
On Sat, 01 Sep 2001 14:47:55 +0200 Graham Leggett <[EMAIL PROTECTED]> wrote: > 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. 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. > If the user specifies "cache this URL range" it would be wrong to > override the user's wishes and not cache something. 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.
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
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
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
On Fri, 2001-08-31 at 14:17, Bill Stoddard 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. > > > > not necessarily. > > we have a situation where we need to uniquly modify outgoing HTML to > > insert ads and tracking things into the HTML (which is different for > > each user) > > we would mod_cache in the middle of the content chain. > > (ie cache the result from the CGI/proxy call) and then run a mod-include > > filter on top of that (possibly pushing the result through gzip) > > > > 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. CACHE_OUT needs to >be the > first CONTENT filter run (or alternately, just move the CACHE_OUT function directly >into > the handler). > > When you mention inserting ads into an HTML stream, I am trying to understand how >this > works. All the output from a page constructed with INCLUDES must be the same mime >type > (text/html, whatever). That would seem to be a considerable limitation to using SSI >(or > custom tags) to assemble pages. we do it via custom SSI tags. the actual HTML image reference changes % curl www.cnet.com >a % curl www.cnet.com >b % diff a b and you'll notice that HTML is slightly different in each case. > > Bill > > > > > > -- Ian Holsman [EMAIL PROTECTED] Performance Measurement & Analysis CNET Networks - (415) 364-8608
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
> > > > > > 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. > > not necessarily. > we have a situation where we need to uniquly modify outgoing HTML to > insert ads and tracking things into the HTML (which is different for > each user) > we would mod_cache in the middle of the content chain. > (ie cache the result from the CGI/proxy call) and then run a mod-include > filter on top of that (possibly pushing the result through gzip) > 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. CACHE_OUT needs to be the first CONTENT filter run (or alternately, just move the CACHE_OUT function directly into the handler). When you mention inserting ads into an HTML stream, I am trying to understand how this works. All the output from a page constructed with INCLUDES must be the same mime type (text/html, whatever). That would seem to be a considerable limitation to using SSI (or custom tags) to assemble pages. Bill
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
On Fri, 2001-08-31 at 13:17, Bill Stoddard wrote: > > > On Friday 31 August 2001 11:48, Graham Leggett wrote: > > > Bill Stoddard wrote: > > > > 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. > > > > > > Hmmm - ok... > > > > > > Part of the job of cache_storage.c is to handle optimisations. What > > > CACHE_IN can do is apply mod_gzip before delivering the content to the > > > cache, and if necessary mod_gunzip can be applied by CACHE_OUT before > > > delivery to any browser who did not negotiate a gzip encoding. > > 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. (hmm.. did someone apply my GZIP filter contribution??) > > > > > 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. not necessarily. we have a situation where we need to uniquly modify outgoing HTML to insert ads and tracking things into the HTML (which is different for each user) we would mod_cache in the middle of the content chain. (ie cache the result from the CGI/proxy call) and then run a mod-include filter on top of that (possibly pushing the result through gzip) > > > > Ryan > > I was playing around with AP_FTYPE_CONTENT+1 :-) yes, it's a hack. Maybe introduce > AP_FTYPE_CACHE and position it right between CONTENT and HTTP_HEADER to prevent any > clashes with third party modules... I am concerned about module FTYPE clashes in > general... We should keep to a minimum the cases where a filter relies on relative > position within its FTYPE class. > > Bill -- Ian Holsman [EMAIL PROTECTED] Performance Measurement & Analysis CNET Networks - (415) 364-8608
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
On Friday 31 August 2001 13:17, Bill Stoddard wrote: > > On Friday 31 August 2001 11:48, Graham Leggett wrote: > > > Bill Stoddard wrote: > > > > 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. > > > > > > Hmmm - ok... > > > > > > Part of the job of cache_storage.c is to handle optimisations. What > > > CACHE_IN can do is apply mod_gzip before delivering the content to the > > > cache, and if necessary mod_gunzip can be applied by CACHE_OUT before > > > delivery to any browser who did not negotiate a gzip encoding. > > 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. > > > 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. > > > > Ryan > > I was playing around with AP_FTYPE_CONTENT+1 :-) yes, it's a hack. Maybe > introduce AP_FTYPE_CACHE and position it right between CONTENT and > HTTP_HEADER to prevent any clashes with third party modules... I am > concerned about module FTYPE clashes in general... We should keep to a > minimum the cases where a filter relies on relative position within its > FTYPE class. That is why I think it should happen as the first HTTP_HEADER filter. This filter is essentially dealing with meta-data, whether the data can be cached, and this FTYPE is essentially used to indicate that all meta-data has been generated by the time this filter type is hit. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
> On Friday 31 August 2001 11:48, Graham Leggett wrote: > > Bill Stoddard wrote: > > > 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. > > > > Hmmm - ok... > > > > Part of the job of cache_storage.c is to handle optimisations. What > > CACHE_IN can do is apply mod_gzip before delivering the content to the > > cache, and if necessary mod_gunzip can be applied by CACHE_OUT before > > delivery to any browser who did not negotiate a gzip encoding. 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. > > 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. > > Ryan I was playing around with AP_FTYPE_CONTENT+1 :-) yes, it's a hack. Maybe introduce AP_FTYPE_CACHE and position it right between CONTENT and HTTP_HEADER to prevent any clashes with third party modules... I am concerned about module FTYPE clashes in general... We should keep to a minimum the cases where a filter relies on relative position within its FTYPE class. Bill
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
On Friday 31 August 2001 11:48, Graham Leggett wrote: > Bill Stoddard wrote: > > 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. > > Hmmm - ok... > > Part of the job of cache_storage.c is to handle optimisations. What > CACHE_IN can do is apply mod_gzip before delivering the content to the > cache, and if necessary mod_gunzip can be applied by CACHE_OUT before > delivery to any browser who did not negotiate a gzip encoding. 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. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
Bill Stoddard wrote: > 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. Hmmm - ok... Part of the job of cache_storage.c is to handle optimisations. What CACHE_IN can do is apply mod_gzip before delivering the content to the cache, and if necessary mod_gunzip can be applied by CACHE_OUT before delivery to any browser who did not negotiate a gzip encoding. 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
> [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
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 -- - [EMAIL PROTECTED]"There's a moon over Bourbon Street tonight..." S/MIME Cryptographic Signature
