I seem to have hit a snag with URL rewriting. The same .htaccess file is running in two different locations, one of which will rewrite correctly, and the other fails miserably.
Correctly, it will rewrite /admin to admin.php and admin/terms to say admin_terms.php or /admin/logs to admin_logs.php.
However, on my own server at home (with exactly the same .htaccess file) it will rewrite /admin to admin.php AND /admin/terms or /admin/logs to admin.php, which is obviously incorrect, and driving me bonkers!
What simple trick am I missing?
There should be NO difference between Apache 2.x versions. However, I suspect that there may be something in the VirtualHost setup which is different between your hosted and home servers (the location of the DocumentRoot in each - but I didn’t see anything like that below) OR there may be something that the WinDoze version doesn’t like (but I didn’t see anything in this regard).
Argh! I don’t like going through masses of code (especially using {THE_REQUEST}) but, since the problem is with the admin redirections …
I would have thought that the [F] needed the Last flag to terminate those block statements but, “if it ain’t broke, don’t fix it!”
Now, using {THE_REQUEST} (e.g., “GET /index.html HTTP/1.1”) is a terrible way to go as you must parse the middle of the string to find the initial file requested (and has NOTHING to do with the result of a redirection (i.e., {REQUEST_URI}). Moreover, having these {THE_REQUEST} variables interleaved with {REQUEST_URI} (RewriteRules can ONLY attempt to match the {REQUEST_URI} string) is horribly confusing!
Tip:
Group the core directives (Options, ErrorDocument and Redirect statements) first then get into the mod_rewrite. When dealing with mod_rewrite, order by the most specific rules first then go to the more generic (being sure not to undo the earlier redirections unintentionally).
Sorry for my long delay in replying, been very busy with a few other things.
Either I’m missing something stupidly simple, or my rewrites are all a little bit messed up! I edited the admin part to what you suggested, but it still rewrites /admin and /admin/users to admin.php whatever I try! I can even get rid of every rewrite in the damned .htaccess file and the rewriting still occurs!
The httpd.conf file is completely empty, and there are no other .htaccess files at all in the DocumentRoot. The rewrite engine itself has now been disabled, and there are no .htaccess files, yet, the application still carries out simple rewrites, like login.php to login and admin.php to admin!
I don’t think so. It’s a complete stock install of the LAMP stack, which just had mod_rewrite installed. This is also occurring, wierdly, on two servers, running Ubuntu, now (one the latest LTS and one 9.10). On a RedHat server it’s absolutely fine.
I didn’t see any Redirect statements (which take precedence over mod_rewrite as mod_alias is a core feature) but your PHP scripts will likely require login.php to be called to satisfy a $_SESSIONS requirement.
RewriteRule ^admin/?$ admin.php [L]
# and
RewriteRule ^login/?$ login.php [L]
in your .htaccess will cause redirections from domain/admin to admin.php and login/ to login.php. Ha! ONLY if mod_rewrite is enabled! Did you comment out all the code or use
RewriteEngine off
to turn mod_rewrite OFF for your latest test? Using RewriteEngine off … RewriteEngine on is like /* … */ in PHP: It’s a great way to comment out a lot of code without #'s.
I was just going to say… the stock “main config file” (httpd.conf) is empty in Ubuntu. My rewrites are lounging around the poker table at
/etc/apache2/apache2.conf
Something other non-Debian 'nix distros don’t do, apparently.
Well, when it was loaded mod_rewrite was loaded in /etc/apahe2/apache2.conf. It fails being enabled in httpd.conf. There was nothing in httpd.conf. Now, to turn off all the URL rewriting I: completely removed the .htaccess file, ran a2dismod rewrite command, and removed the <IfModule> block from the apache2.conf file, and restarted Apache and the erronous redirects still continued. I took a look at phpinfo() output from the working and non working servers and they seem almost identical. The interesting rewrite section, is exactly the same. I’m almost all out of ideas now. Oh, and the Directory is ~/www for the root Apache default site.
Did you check for an equivalent of the httpd-vhosts.conf file (look for an include at the end of your apache2.conf)? Your “hidden directives” may be there!
Just been having a good old poke around in Apache, and looked for all of my included files. Looked in conf.d folder, and there’s nothing there, as well as httpd.conf a bit on the empty side! Other than that, can’t see anything else being included from apache2.conf
However, just poked my nose into sites-enabled/000-default and for some reason (although don’t ask me why!) this seems a little bit suspicious.
DocumentRoot /home/adam/www
<Directory />
Options FollowSymLinks
AllowOverride All
</Directory>
<Directory /home/adam/www>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
</Directory>
Now then, time to play spot the idiot. Removed the MultiViews from that and it works fine. Thanks for everyones time, and invaluable advice. I’ve learnt a fair bit from going on the wild goose chase, through almost every Apache config file imaginable!
Options MultiViews is such a PITA! On the other hand, kudos to you for spotting that and fixing the problem without assistance.
Others:
MultiViews allows you to insert the filename of a script in the middle of a {path_to} string. IMHO, it’s a silly way to create URIs and, from Adam’s experience, it can safely be said that it causes more problems than it’s worth.
Great info, then. I checked my setup: it is certainly the default setting, and I’ve added DK’s explanation and -'d the Multiviews.
I wonder why they have it in there.
Hm, someone must have thought it helps keep stuff working even if a mistake in pathnames was made. Silent errors kinda bother me.
*edit I asked hubby what this was good for/why it existed.
Still seems like something people should need to consciously set rather than remember to un-set.