Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
Joshua Slive wrote: Justin Erenkrantz wrote: --On Tuesday, March 8, 2005 9:38 PM +0200 Eli Marmor [EMAIL PROTECTED] wrote: It depends if you need it only for the server configuration, or for dir_config; In the latter case, you don't have another choice, you just NEED the +- Actually, cache can't respect any dir config's (because it is a quick handler) so Joshua is right - we shouldn't follow the +-. -- justin I don't think it matters anyway. Note that AllowOverride handles dir configs. All the +/- syntax buys you is being able to write Directive Foo Bar Baz Directory /foo Directive -Bar +Boo /Directory Instead of Directive Foo Bar Baz Directory /foo Directive Foo Baz Boo /Directory Both of you are right; What I meant to say was that in dir config, you MUST have +-; In server config, you MAY have +-. Time to define the exact directive and names? -- Eli Marmor [EMAIL PROTECTED] Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-5237338 Kfar-Saba 44641, Israel
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
--On Wednesday, March 9, 2005 9:47 AM +0200 Eli Marmor [EMAIL PROTECTED] wrote: Time to define the exact directive and names? I'd start with all of the directive that mod_cache currently exposes that are binary (on/off). At a quick glance, that looks like CacheIgnoreCacheControl, CacheIgnoreNoLastMod, CacheStoreNoStore, CacheStorePrivate. For a first cut, it probably just makes sense to drop Cache from the prefix and see how it goes. -- justin
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
Justin Erenkrantz wrote: --On Wednesday, March 9, 2005 9:47 AM +0200 Eli Marmor [EMAIL PROTECTED] wrote: Time to define the exact directive and names? I'd start with all of the directive that mod_cache currently exposes that are binary (on/off). At a quick glance, that looks like CacheIgnoreCacheControl, CacheIgnoreNoLastMod, CacheStoreNoStore, CacheStorePrivate. For a first cut, it probably just makes sense to drop Cache from the prefix and see how it goes. -- justin That's all?! Let me quote myself (and this is not the complete list): If I recall correctly, there were MANY conditions in mod_cache that prevented caching (like checking for a POST method, no-store, no-cache, auth, GET args, private, public, must-revalidate, maxage, etc.). The complete list may be long, but if we want to allow offline caching, we must precede a condition before any rule of mod_cache.c that prevents caching in any case, and I don't see any serious difference (performance, code size, memory size) between if (conf-something!=0) and if (conf-something SOMETHING != 0). So we don't need to have one directive/bit for many conditions, as long as it is done in a friendly way for the users (i.e. there are 3-4 pre-defined constants which mean cache nothing, default cache, and cache everything - for offline browsing). In addition, the entity must be updated to contain more attributes of the request (args, POST args, cookies, etc.). And to find it fast, the key generated by cache_generate_key must be based on more things (such as args). Because sometimes a dynamic site may have thousands pages, all of them with the same URL but with different args. By the way: the whole concept is not according to RFC 2616, but you can't do offline caching without contradicting the RFC, and we already have a lot of other directives that allow the users to be incompatible with the RFC, *IF THIS IS WHAT THEY WANT AND THEY KNOW WHAT THEY ARE DOING*. -- Eli Marmor [EMAIL PROTECTED] Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-5237338 Kfar-Saba 44641, Israel
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
--On Wednesday, March 9, 2005 7:42 PM +0200 Eli Marmor [EMAIL PROTECTED] wrote: That's all?! Let me quote myself (and this is not the complete list): If I recall correctly, there were MANY conditions in mod_cache that prevented caching (like checking for a POST method, no-store, no-cache, auth, GET args, private, public, must-revalidate, maxage, etc.). The complete list may be long, but if we want to allow offline caching, we must precede a condition before any rule of mod_cache.c that prevents caching in any case, and I don't see any serious difference (performance, code size, memory size) between if (conf-something!=0) and if (conf-something SOMETHING != 0). So we don't need to have one directive/bit for many conditions, as long as it is done in a friendly way for the users (i.e. there are 3-4 pre-defined constants which mean cache nothing, default cache, and cache everything - for offline browsing). As you know, we don't currently have directives for most of these items. We can gradually add them. However, to make your patch easier to review, I'd suggest taking it piecemeal - convert the current binary options to a CacheOptions directive and then once that is complete and accepted in the tree, we can then add new options one at a time. We like smaller and easier-to-review patches. =) Does this make sense? -- justin
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
Eli Marmor wrote:
[..cut..]
In addition, the entity must be updated to contain more attributes of
the request (args, POST args, cookies, etc.). And to find it fast, the
key generated by cache_generate_key must be based on more things (such
as args). Because sometimes a dynamic site may have thousands pages,
all of them with the same URL but with different args.
The args are already used by cache_generate_key (see cache_storage.c lines
301
till 310, code from 2.0.53):
apr_status_t cache_generate_key_default( request_rec *r, apr_pool_t*p,
char**key )
{
if (r-hostname) {
*key = apr_pstrcat(p, r-hostname, r-uri, ?, r-args, NULL);
}
else {
*key = apr_pstrcat(p, r-uri, ?, r-args, NULL);
}
return APR_SUCCESS;
}
Regards
Rdiger
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
[EMAIL PROTECTED] wrote:
Eli Marmor wrote:
[..cut..]
In addition, the entity must be updated to contain more attributes of
the request (args, POST args, cookies, etc.). And to find it fast, the
key generated by cache_generate_key must be based on more things (such
as args). Because sometimes a dynamic site may have thousands pages,
all of them with the same URL but with different args.
The args are already used by cache_generate_key (see cache_storage.c lines 301
till 310, code from 2.0.53):
apr_status_t cache_generate_key_default( request_rec *r, apr_pool_t*p,
char**key )
{
if (r-hostname) {
*key = apr_pstrcat(p, r-hostname, r-uri, ?, r-args, NULL);
}
else {
*key = apr_pstrcat(p, r-uri, ?, r-args, NULL);
}
return APR_SUCCESS;
}
Oops, you're right...
But yet, POST args are not used (it requires an input filter BTW), as
well as other parameters which may affect dynamic caching (cookies
etc.).
People may be afraid of a total caching and/or input filter, so these
options will be turned off by default, but we still owe them for the
rest.
--
Eli Marmor
[EMAIL PROTECTED]
Netmask (El-Mar) Internet Technologies Ltd.
__
Tel.: +972-9-766-1020 8 Yad-Harutzim St.
Fax.: +972-9-766-1314 P.O.B. 7004
Mobile: +972-50-5237338 Kfar-Saba 44641, Israel
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
Justin Erenkrantz wrote: On Tue, Mar 08, 2005 at 03:57:55AM +0100, Sander Striker wrote: Hi, Currently CacheIgnoreCacheControl On only ignores Cache-Control: no-cache and Pragma: no-cache. I'd like to add ignoring Cache-Control: max-age=... and Cache-Control: min-fresh=... as well. This would give the admin more control, and would also make the directive slightly more intuitive IMO. This because different browsers do different things. One will send a Cache-Control: no-cache on a refresh, and one will send a Cache-Control: max-age=... It would be nice if the effect would be the same for both. Thoughts? While I think this is a good idea, I'd like to consider renaming this particular directive as I think the name is really confusing. Does that mean you want me to hold off on committing this patch pending a directive rename? Isn't that a seperate issue? My concern is that CacheIgnoreCacheControl only refers to the request's Cache-Control not the origin response's Cache-Control header. But, I like that separation because having it refer to both is too coarse-grained, I think. Definately agreed. Ignoring response Cache-Control is in another league than ignoring the request Cache-Control. But, I don't have any real ideas for what an alternative name is. -- justin CacheIgnoreServerCacheControl? Sander
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
On Tue, Mar 08, 2005 at 06:01:35PM +0100, Sander Striker wrote: While I think this is a good idea, I'd like to consider renaming this particular directive as I think the name is really confusing. Does that mean you want me to hold off on committing this patch pending a directive rename? Isn't that a seperate issue? Nah, go ahead and commit if you like. It's just that you brought up the point of making the directive more intuitive - and I have problems from the word go on this particular directive being intuitive. It's not. In order to understand what this directive does, you need to know what Cache-Control from the RFC means - and that's not intuitive. I'd like something that expresses the concept that we will serve cached content even if the client asks for 'fresh' content. The closest I can come up with is 'CacheServeStale' - but that's not quite right or even precise either. My concern is that CacheIgnoreCacheControl only refers to the request's Cache-Control not the origin response's Cache-Control header. But, I like that separation because having it refer to both is too coarse-grained, I think. Definately agreed. Ignoring response Cache-Control is in another league than ignoring the request Cache-Control. Correct. But, I don't have any real ideas for what an alternative name is. -- justin CacheIgnoreServerCacheControl? Per above, I don't like the phrase Cache-Control. -- justin
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
Justin Erenkrantz wrote: On Tue, Mar 08, 2005 at 06:01:35PM +0100, Sander Striker wrote: While I think this is a good idea, I'd like to consider renaming this particular directive as I think the name is really confusing. Does that mean you want me to hold off on committing this patch pending a directive rename? Isn't that a seperate issue? Nah, go ahead and commit if you like. It's just that you brought up the point of making the directive more intuitive - and I have problems from the word go on this particular directive being intuitive. It's not. In order to understand what this directive does, you need to know what Cache-Control from the RFC means - and that's not intuitive. I'd like something that expresses the concept that we will serve cached content even if the client asks for 'fresh' content. The closest I can come up with is 'CacheServeStale' - but that's not quite right or even precise either. CacheForOffline? (or Cache4Offline) Offline browsing is the main case where you need such absolute caching. But it requires you to cache EVERYTHING. Including dynamic content, and even different content according to different POST input. Maybe two directives are needed, one for using the cache only if the cookies are the same. All of that requires changing the caching mechanism to keep POST input, cookies, etc. I started to do it in the past, and planned to contribute it when it would be ready, but held on when the major modifications of mod_cache started. I think that Brian Akins made a similar patch too, and wanted to contribute it, but failed to pass CNN's lawyers. If I recall correctly, he volunteered to give tips. -- Eli Marmor [EMAIL PROTECTED] Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-5237338 Kfar-Saba 44641, Israel
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
Justin Erenkrantz wrote: It's just that you brought up the point of making the directive more intuitive - and I have problems from the word go on this particular directive being intuitive. It's not. In order to understand what this directive does, you need to know what Cache-Control from the RFC means - and that's not intuitive. I'd like something that expresses the concept that we will serve cached content even if the client asks for 'fresh' content. Agreed. The closest I can come up with is 'CacheServeStale' - but that's not quite right or even precise either. Cache-Control is per definition a bit of a tough thing to translate to a term like Stale or Fresh, since it can require both. [...] Per above, I don't like the phrase Cache-Control. -- justin Fair enough. What about: CacheIgnoreClientAgeRequirements ? A bit long maybe. Sigh. I'm not very good at coming up with short yet descriptive directive names I'm afraid. Sander
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
Eli Marmor wrote: [...] CacheForOffline? (or Cache4Offline) Offline browsing is the main case where you need such absolute caching. But it requires you to cache EVERYTHING. Including dynamic content, and even different content according to different POST input. Maybe two directives are needed, one for using the cache only if the cookies are the same. All of that requires changing the caching mechanism to keep POST input, cookies, etc. I think you just proved Justins point. Above is all about response Cache-Control. The current CacheIgnoreCacheControl only affects request Cache-Control. Confuzzled yet ;) :) Sander
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
Sander Striker wrote: Eli Marmor wrote: [...] CacheForOffline? (or Cache4Offline) Offline browsing is the main case where you need such absolute caching. But it requires you to cache EVERYTHING. Including dynamic content, and even different content according to different POST input. Maybe two directives are needed, one for using the cache only if the cookies are the same. All of that requires changing the caching mechanism to keep POST input, cookies, etc. I think you just proved Justins point. Above is all about response Cache-Control. The current CacheIgnoreCacheControl only affects request Cache-Control. Confuzzled yet ;) :) Sander If I recall correctly, there were MANY conditions in mod_cache that prevented caching (like checking for a POST method, no-store, no-cache, auth, GET args, private, public, must-revalidate, maxage, etc.). My idea was to have one directive, with an option for each of them, including the conditions that are already supported, plus two special options - one that represents the empty set of options, and one that turns on all of the options. -- Eli Marmor [EMAIL PROTECTED] Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-5237338 Kfar-Saba 44641, Israel
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
--On Tuesday, March 8, 2005 8:12 PM +0200 Eli Marmor [EMAIL PROTECTED] wrote: If I recall correctly, there were MANY conditions in mod_cache that prevented caching (like checking for a POST method, no-store, no-cache, auth, GET args, private, public, must-revalidate, maxage, etc.). My idea was to have one directive, with an option for each of them, including the conditions that are already supported, plus two special options - one that represents the empty set of options, and one that turns on all of the options. Hmm. That's an interesting approach. How about an ITERATE directive with a bit-wise field that represent their value in the config structure? I sort of like that... =) To be clear, something like: CacheOptions +StorePrivate +IgnoreClientControl +IgnoreServerControl +CachePOST +CacheAuth CacheOptions +all CacheOptions -all Feel like writing a patch? =) -- justin
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
Justin Erenkrantz wrote: --On Tuesday, March 8, 2005 8:12 PM +0200 Eli Marmor [EMAIL PROTECTED] wrote: If I recall correctly, there were MANY conditions in mod_cache that prevented caching (like checking for a POST method, no-store, no-cache, auth, GET args, private, public, must-revalidate, maxage, etc.). My idea was to have one directive, with an option for each of them, including the conditions that are already supported, plus two special options - one that represents the empty set of options, and one that turns on all of the options. Hmm. That's an interesting approach. How about an ITERATE directive with a bit-wise field that represent their value in the config structure? I sort of like that... =) To be clear, something like: CacheOptions +StorePrivate +IgnoreClientControl +IgnoreServerControl +CachePOST +CacheAuth CacheOptions +all CacheOptions -all Feel like writing a patch? =) -- justin Exactly. This is what I started to code (using an ancient release...). I stole some code from Options. -- Eli Marmor [EMAIL PROTECTED] Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-5237338 Kfar-Saba 44641, Israel
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
Eli Marmor wrote: Justin Erenkrantz wrote: --On Tuesday, March 8, 2005 8:12 PM +0200 Eli Marmor [EMAIL PROTECTED] wrote: If I recall correctly, there were MANY conditions in mod_cache that prevented caching (like checking for a POST method, no-store, no-cache, auth, GET args, private, public, must-revalidate, maxage, etc.). My idea was to have one directive, with an option for each of them, including the conditions that are already supported, plus two special options - one that represents the empty set of options, and one that turns on all of the options. Hmm. That's an interesting approach. How about an ITERATE directive with a bit-wise field that represent their value in the config structure? I sort of like that... =) To be clear, something like: CacheOptions +StorePrivate +IgnoreClientControl +IgnoreServerControl +CachePOST +CacheAuth CacheOptions +all CacheOptions -all Feel like writing a patch? =) -- justin Exactly. This is what I started to code (using an ancient release...). I stole some code from Options. I.e. from set_options() of server/core.c -- Eli Marmor [EMAIL PROTECTED] Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-5237338 Kfar-Saba 44641, Israel
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
Justin Erenkrantz wrote: CacheOptions +StorePrivate +IgnoreClientControl +IgnoreServerControl +CachePOST +CacheAuth CacheOptions +all CacheOptions -all I suggest avoiding the +/- syntax which has proven confusing to many users and adds very little in functionality. Just use CacheOptions StorePrivate IgnoreClientControl IgnoreServerControl CachePOST CacheAuth CacheOptions All CacheOptions None Use AllowOverride as your example rather than Options. Joshua.
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
Joshua Slive wrote: Justin Erenkrantz wrote: CacheOptions +StorePrivate +IgnoreClientControl +IgnoreServerControl +CachePOST +CacheAuth CacheOptions +all CacheOptions -all I suggest avoiding the +/- syntax which has proven confusing to many users and adds very little in functionality. Just use CacheOptions StorePrivate IgnoreClientControl IgnoreServerControl CachePOST CacheAuth CacheOptions All CacheOptions None Use AllowOverride as your example rather than Options. It depends if you need it only for the server configuration, or for dir_config; In the latter case, you don't have another choice, you just NEED the +- -- Eli Marmor [EMAIL PROTECTED] Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-5237338 Kfar-Saba 44641, Israel
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
--On Tuesday, March 8, 2005 9:38 PM +0200 Eli Marmor [EMAIL PROTECTED] wrote: It depends if you need it only for the server configuration, or for dir_config; In the latter case, you don't have another choice, you just NEED the +- Actually, cache can't respect any dir config's (because it is a quick handler) so Joshua is right - we shouldn't follow the +-. -- justin
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
Justin Erenkrantz wrote: --On Tuesday, March 8, 2005 9:38 PM +0200 Eli Marmor [EMAIL PROTECTED] wrote: It depends if you need it only for the server configuration, or for dir_config; In the latter case, you don't have another choice, you just NEED the +- Actually, cache can't respect any dir config's (because it is a quick handler) so Joshua is right - we shouldn't follow the +-. -- justin I don't think it matters anyway. Note that AllowOverride handles dir configs. All the +/- syntax buys you is being able to write Directive Foo Bar Baz Directory /foo Directive -Bar +Boo /Directory Instead of Directive Foo Bar Baz Directory /foo Directive Foo Baz Boo /Directory Joshua.
