SetEnvIf

[tangor]

Which is correct? (Note, I do not run PHP).

SetEnvIf Request_URI "\.php" ban

or

SetEnvIf Request_URI "\.(php)" ban

or?

Half the time it works and delivers a 403 (desired). The other half responds with a 302 (not desired)

However, some of the 403 MIGHT come from earlier entries in my .htaccess against UA or Referer.

REWRITE does not work on this particular host... the few times I've tried to use REWRITE it takes the server down with 500s.

Any thoughts?

[jdMorgan]

SetEnvIf Request_URI "\.php$" ban

would be more correct if you wish to deny access to /<anything>.php but not necessarily deny access to /notes.php.txt or /index.php5
Using ambiguous patterns can lead to unexpected problems later, so I suggest making your patterns as specific as possible for your actual (and thoroughly-commented) needs.

The answer to the "doesn't work" aspect of your problem hinges on whatever it is that you do with the "ban" variable set by this SetEnvIf directive. If you don't have a directive in the file that says something like

 Deny from env=ban 

then the SetEnvIf by itself only sets the "ban" variable, and does nothing else.

Don't be mislead by the concept of "earlier" and "later" .htaccess entries, and note that I said nothing about whether the "Deny from" referred-to above was "before" or "after" the SetEnvIf. These "earlier" and "later" terms are largely meaningless in .htaccess, because the only significance to directive order is to the modules to which the directives belong. For example, consider these two snippets from two different .htaccess files:

SetEnvIf Request_URI "\.php$" ban
Deny from env-ban 

 Deny from env-ban
SetEnvIf Request_URI "\.php$" ban 

What is the difference in the behavior of these two files?

The answer is "none" - Both will work exactly the same, because the SetEnvIf directive is processed first by mod_setenvif, and the "Deny from" directive is processed later by mod_access in either case... assuming a properly-configured server.

So remember that only directives belonging to the same Apache module are processed in the order that they are encountered in your .htaccess file. All directives belonging to other modules will also be executed in order by those other modules. But the order in which the Apache modules process their directives is controlled by the server configuration, and not by anything related to the order in which you place directives in your .htaccess file.

So don't think of .htaccess files as "scripts" because they are not executed in straight top-to-bottom order.

Back on-topic... Look to be sure that you've got that "Deny from env=ban" directive somewhere on your file. If not, then that is the problem.

See Apache mod_setenvif and mod_access documentation for more info.

Jim

[jdMorgan]

You might also want to re-visit your mod_rewrite problem, as hosts which do not support mod_rewrite are getting fairly rare these days... Just be sure that you include the "full set-up" necessary to use mod_rewrite, and test with a single, simple rule.

At most, the "set-up" takes two lines before your first RewriteRule, but you may not need the two setup lines, or you may need only one of them. In fact, the first line might not even be allowed on your server - it depends on how your host configured the server.

The only way to find out is to test. If you get an error, look at the server error log -- ask your host if you don't know where it is. The error log will often tell you (or us) exactly what is wrong.

Options +FollowSymLinks
RewwriteEngine on
#
RewriteRule ^go-to-google\.html$ http://www.google.com/ [R-301,L]

Now if you request the page "/go-to-google.html from your server, you should land at www.google.com.

Jim

[tangor]

Many thanks, Jim. As usual clearly stated.

I'm getting odd results along the line of:

GET //inc/shows.inc.php?cutepath=http://61.40.130.nn:8080//design07/user/user/info/banner_dovolenka_backup.jpg? 302

GET /inc/shows.inc.php?cutepath=http://61.40.130.nn:8080//design07/user/user/info/banner_dovolenka_backup.jpg%3f 403

Same IP same UA, within the same second or within seconds of each other.

I have NO php at this site and do not intend to ever use it, hence the desire to put \.php into the SetEnvIf Request_URI . Since January 8,163 .php files have been requested. 5,768 have 403'd properly.... the rest end up as 302s...

Most of the requests come in VERY FAST... wondering if that might be part of the problem? Seems like the first one is caught as a 403 but subsequent from same IP, even a different URI, goes through as a 302...

As none of these files exist they can't be indexed, thus no worries in that regard, but I'd like to do this correctly and 403 these and let 404 do it's real work.

However, and this may be important, PHP is available to me, but as stated above, have no desire or intent to ever use it. Don't know if that makes a difference, but does describe the host capabilities.

[jdMorgan]

Note that in your limited example, the URL-path that got redirected starts with a double-slash. This may be mod_dir, mod_negotiation, or mod_speling trying to correct this incorrect path.

But please address this aspect of my post above:

Look to be sure that you've got that "Deny from env=ban" directive somewhere on your file. If not, then that is the problem.

Jim

[tangor]

Of course... and that part has been working for several years as regards dealing with ua's and referers... it's only the request that sometimes works and sometimes doesn't.

I had noted the // and on second look all are 302. I'll take that as internal on the server and not going out. Sounds like a call to support might be a good idea.

Thanks!

[jdMorgan]

No, that's a 302-Found client redirect. If you don't use 302 redirects for anything, then a call to support is certainly justified.

And sorry, but we cannot assume anything here or we we waste our time and yours. So "of course" should be either "yes" or "no," because no-one else knows but you...

Jim

[tangor]

I will say Yes then, and thank for your helping me with Deny From and SetEnvIfNoCase 4 years back... but I'm pretty sure you might not remember that given how many of these queries you field each year!

The operative parts of my .htaccess (culled to one example each)

Options SymLinksIfOwnerMatch Includes

SetEnvIfNoCase User-Agent "grub" ban
SetEnvIfNoCase Referer "viagra" ban
SetEnvIf Request_URI "\.php" ban
SetEnvIf Request_URI "(robots\.txt)$" pass

Order Deny,Allow

<FilesMatch "\.(htaccess|htpasswd)$">
Deny from all
</FilesMatch>

<LimitExcept GET POST>
Deny from all
</LimitExcept>

<Limit GET POST>
Deny from nn.nn.nn.nn
Deny from env=ban
Allow from env=pass
</Limit>

[jdMorgan]

Are there any 302 redirects in your file anywhere? Or in any .htaccess files below this one in the file-structure? These would be

Redirect /x http://example.com/z
RedirectTemp /x http://example.com/z
RedirectMatch ^/x http://example.com/z
Redirect 302 /x http://example.com/z
RedirectMatch 302 ^/x http://example.com/z
Redirect Temp /x http://example.com/z
RedirectMatch temp ^/x http://example.com/z
Redirect /x /z
RedirectTemp /x /z
RedirectMatch ^/x /z
Redirect 302 /x /z
RedirectMatch 302 ^/x /z
Redirect temp /x /z
RedirectMatch Temp ^/x /z
RewriteRule ^x http://example.com/z
RewriteRule ^x http://example.com/z [L]
RewriteRule ^x http://example.com/z [R]
RewriteRule ^x http://example.com/z [R,L]
RewriteRule ^x http://example.com/z [R=302]
RewriteRule ^x http://example.com/z [R=302,L]
RewriteRule ^x http://example.com/z [R=temp]
RewriteRule ^x http://example.com/z [R=Temp,L]
RewriteRule ^x /z [R]
RewriteRule ^x /z [R,L]
RewriteRule ^x /z [R=302]
RewriteRule ^x /z [R=302,L]
RewriteRule ^x /z [R=temp]
RewriteRule ^x /z [R=temp,L]

... basically any variation of a redirect with either a 302 or "temp" specified explicitly, or any redirect with no specific type specified.

Jim

[tangor]

No. I have six (6) RedirectPermanent /afile [mysite.com...]

That's all the redirects I have. (Last in .htaccess, though I don't think that makes much difference.)

[jdMorgan]

In that case, it sounds like your host has some code to 302-redirect requests for "//whatever" to "/whatever", and that is what you're seeing... or it's mod_dir that is doing this.

This isn't truly harmful security-wise, but it is rather a waste of server resources to redirect unwelcome requests, and so perhaps worth a call to inquire about.

Jim

[tangor]

That's what it turned out to be. At the same time I inquired as to why REWRITE doesn't work when most everything else does...

Server this site is about 6 years old, though running latest Apache... locked down back then... they offered to move me to one of their newer systems with a bit more control. I asked "how much?"

As expected there is an upprice... asked if they could correct the 302 issue as the current set up has served quite well and my requirements are relatively minimal on this site.

Thanks! (Didn't think I was doing it wrong... getting unexpected results!)

Appreciate it, Jim!

[jdMorgan]

Another thing to look into it that using <Files> and <FilesMatch> directives changes the processing order of the enclosed directives such that they are executed later than they would be if not so enclosed.

This is a somewhat 'difficult' subject, but the Apache documentation contains a page about how different <Directory>, <Location>, and <Files> sections are merged if you want to look into it. It is linked from some of the sections which document those specific directives.

It is possible that by re-writing parts of your code to eliminate the <Files> and <FilesMatch> sections, you might be able to correct the problem -- even with the current server set-up.

To be specific, it's possible that if you replace those <Files> and <FilesMatch> sections, you could get your access controls to execute before your host's "//" redirect kicks in, and this problem might then go away.

This would require changing some of the logic so that RewriteRules are used instead of "Deny froms" inside <Files> containers, and perhaps using more <SetEnvIf> directives to replace some other <Files> constructs. This would not be a trivial project, but it would not involve a terribly huge amount of work.

Jim