RFE: Control of HTTP cache control headers within mod_rewrite rules
Hello all, Recent versions of Firefox, IE, and Chrome will now cache HTTP 301 and 302 responses based on the cache control headers, (roughly) in line with the HTTP spec. This is, in general, a good thing, but can cause some issues, as I've discussed here: http://rwec.co.uk/q/cached-redirs When using mod_rewrite to produce such responses, there is no way of influencing the cache control headers, so browsers will fall back to their default behaviour by redirect type. (You could probably do something clever with mod_expires or mod_headers, but getting it to apply only to the relevant redirect would be tricky to say the least.) As a minimum, it would be nice to be able to specify a cache life time; in English: send a 302, allow browser to cache for a week; or send a 301, but limit browser to cache for 1 month. This could be a new RewriteRule flag, using syntax similar to mod_expires, e.g. RewriteRule /example http://example.com [R=302,CL=604800] RewriteRule /example2 http://example.com [redirect=permanent,cachelifetime=1 month] A more advanced version would be to allow custom HTTP headers using an [HH=Foo:Bar] syntax or similar, but this may be going a bit far. Does anyone have any thoughts? Is there somewhere I could file this that a friendly developer might pick up? Regards, -- Rowan Collins [IMSoP]
Re: RFE: Control of HTTP cache control headers within mod_rewrite rules
A more advanced version would be to allow custom HTTP headers using an [HH=Foo:Bar] syntax or similar, but this may be going a bit far. Does env=xxx in the Header directive then R=...,E= in RewriteRule work?
Re: RFE: Control of HTTP cache control headers within mod_rewrite rules
On 23/10/2011 20:54, Eric Covener wrote:
A more advanced version would be to allow custom HTTP headers using an
[HH=Foo:Bar] syntax or similar, but this may be going a bit far.
Does env=xxx in the Header directive then R=...,E= in RewriteRule work?
Hi Eric,
I haven't got a test environment to hand right now, but that looks
promising - I didn't spot the conditional form of Header directive;
clearly I should have read the page more carefully. ;)
I'm not sure if directive order would matter, but in principle maybe
something like this would work:
Header set Cache-Control max-age=%{CACHE_LIFETIME}e env=CACHE_LIFETIME
RewriteRule /example http://example.com [R=302,E=CACHE_LIFETIME:604800]
I'll have to play around, and let you know how I get on - thanks for the
tip.
Regards,
Rowan
Re: LUA hook ordering block/section form
On Monday 17 October 2011, Eric Covener wrote: I'm thinking of tweaking mod_lua to allow most LuaHook* to run early' or late. Currently they all run APR_HOOK_MIDDLE which can be kind of limiting. Would it be acceptable to just register three hooks for each phase (early/middle/late) and continue to bail out quickly if no lua code is registered? Or does it need to be smarter about registering the hooks as the admin asks for early or late scripts or blocks? I think simple is ok for now. We can always optimize later. I am tentatively using APR_HOOK_FIRST-1 and APR_HOOK_LAST+1 for the alternate ordering, since you can't provide predecessors/successors and APR_HOOK_FIRST would still have you bumping into e.g. mod_rewrite. APR_HOOK_REALLY_FIRST/LAST also seems like it would step on the toes of things (in an unpredictable way). Sounds ok. I agree that APR_HOOK_REALLY_FIRST/LAST should be out of bounds. If we let the user pick an exact order (but still no predecssors/successors) I guess we could register the exact hook ordinals as we see them but this seems like too much. Is it possible to configure the hooks in .htaccess? You can't register new hooks in .htaccess, so if yes, you would be limited to the preregistered hooks, anyway.
Re: svn commit: r1187992 - /httpd/httpd/trunk/modules/filters/mod_filter.c
On Oct 23, 2011, at 3:19 PM, s...@apache.org wrote:
else if (r-content_type) {
const char **type = provider-types;
AP_DEBUG_ASSERT(type != NULL);
while (*type) {
-if (strcmp(*type, r-content_type) == 0) {
+/* Handle 'content-type;charset=...' correctly */
+size_t len = strcspn(r-content_type, ; \t);
+if (strlen(*type) == len
+ strncmp(*type, r-content_type, len) == 0) {
match = 1;
break;
}
type++;
}
Wouldn't this be faster as
else if (r-content_type) {
+ /* Handle 'content-type;charset=...' correctly */
+ size_t len = strcspn(r-content_type, ; \t);
const char **type = provider-types;
AP_DEBUG_ASSERT(type != NULL);
while (*type) {
+if ((strncmp(*type, r-content_type, len) == 0)
+(*type[len] == '\0')) {
match = 1;
break;
}
type++;
}
or am I just trying to outwit the compiler?
Roy
Re: svn commit: r1187986 - in /httpd/httpd/trunk/docs/manual: custom-error.xml mod/core.xml
On Oct 23, 2011, at 3:09 PM, s...@apache.org wrote: --- httpd/httpd/trunk/docs/manual/mod/core.xml (original) +++ httpd/httpd/trunk/docs/manual/mod/core.xml Sun Oct 23 22:09:34 2011 @@ -1165,6 +1165,7 @@ in case of an error/description ErrorDocument 404 /cgi-bin/bad_urls.plbr / ErrorDocument 401 /subscription_info.htmlbr / ErrorDocument 403 Sorry can't allow you access today + ErrorDocument 403 Forbidden! /example pAdditionally, the special value codedefault/code can be used I don't think that change was intended, right? Looks like an error test. Roy
