Performance question

Efficiency of Rewriterule

[jlnaman]

I often see:
RewriteRule .* -
but that supposedly causes another pass.
I assume that .? also causes another pass
Would RewriteRule !^/ -
be more efficient, i.e. not cause another pass?

I'm still on Apache 2.2
RewriteCond %{ENV:AllowErrPHP} 1
RewriteRule .? - [L]
RewriteCond %{ENV:ROBOTGONE} 1
RewriteRule .? - [G,L]
RewriteCond %{ENV:BADBOT} 1
RewriteRule .? - [F,L]

[phranque]

http://httpd.apache.org/docs/current/rewrite/flags.html [httpd.apache.org]:

When using [F] (or [G]), an [L] is implied - that is, the response is returned immediately, and no further rules are evaluated.

when using the [L] alone:

... once the rules have been processed, the rewritten request is handed back to the URL parsing engine to do what it may with it. It is possible that as the rewritten request is handled, the .htaccess file or <Directory> section may be encountered again, and thus the ruleset may be run again from the start. Most commonly this will happen if one of the rules causes a redirect - either internal or external - causing the request process to start over.

[lucy24]

When and where are the environmental variables getting set? Using mod_rewrite when there are other options tends to be shooting-flies-with-an-elephant-rifle territory. Did you try a

Deny from env=blahblah

line instead? mod_setenvif may or may not execute before mod_rewrite; it definitely happens before mod_authz-whatsit.

Using .? instead of .* may get the server through the rule a nanosecond sooner, because it only has to check for "was there a request?" instead of "did the request potentially contain lots of stuff?" But no matter what you do, [L] (or implied [L] such as [G] or [F]) doesn't stop anything. It just kicks you out of mod_rewrite on the present pass. Requests keep cycling through all mods until everything rinses clean, i.e. no new changes.

[jlnaman]

My (psychological) problem is that I wanted to post-process a 403 and Deny from doesn't seem to invoke ErrorDocument 403 xxx.php. So I split things up into ENV variables such that certain URLs return a 204 nocontent and others a 410 Gone, etc. The amount of CPU and resources used is negligible and I'm getting the results I wanted, so the question is now moot. Thanks!

[lucy24]

Deny from doesn't seem to invoke ErrorDocument 403 xxx.php

It certainly ought to, if the 403 originates with the server. If the 403 originates from a php script, you have to "include" your 403 page because as far as the server knows, it's all good and 200. And no matter where the 403 originates, if it comes from Apache you have to poke a hole for your error documents or else they, too, will be denied.

What does "post-process" mean? In my lexicon the term has a different and wholly unrelated meaning ;)

[jlnaman]

htaccess includes ErrorDocument 403 xxx.php.
Post-process: Apache encounters Deny From env=bad
wishfully: Apache calls xxx.php which does things (perhaps writes to a special log file)and then issues a header('HTTP/1.0 402 Payment Required ', true, 402); and exits. Post in the sense that Apache exited normal processing on the Deny and I was viewing it as an "Error Handling" process. I'm clearly naive and uneducated on Apache. I don't mean to waste your time ...

[lucy24]

Do you have an exemption for xxx.php? Something like

<Files "xxx.php">
Order Allow,Deny
Allow from all
</Files>

and also, if necessary,

RewriteRule ^xxx\.php - [L]

before all other RewriteRules. (That is: before [F] or [G] or external redirects.) If you don't have these exemptions, the request will never be allowed to see your 403 document.

In fact you seem to be describing the opposite of the usual php-include issue. Normally the oversight is that the server returns a 200 so it doesn't know it was supposed to send out an error document. Here it looks as if the server is returning a 403, even if the user ends up receiving some other response. Interesting!