I found that one of the main things that cause .htaccess rewrite rulesets to do seemingly bizarre things is when Apache decides to try to apply them inside a subrequest. This is to the extent that I now always use the [NS] flag on my rules or use a prefix rule
RewriteCond %{IS_SUBREQ}%{ENV:END} t|1 [NC]
RewriteRule ^ - [L]
(The %{ENV:END} bit just allows me to use E=END:1 to do the same as the V2.4 END flag.)
My Q is: can anyone give me of a good usecase where I wouldn't want to do this? (or alternatively where I would want to use the special -U or -F condition patterns).
I realise that there may be many that I haven't thought of, but the A tick goes to the first valid one.
I'd guess the typical situations where you'd want to apply rewrite rules to subrequests are more or less the same as the one where you'd use symlinks inside your document root.
For a plausible example, let's say you're using Server Side Includes, and have a bunch of files scattered around with suffixes like .html, .shtml and .htm, and perhaps some uppercase variants of these too. At some point, you decide to standardize on the .html suffix, and rename all your files accordingly. But you still have a bunch of legacy code and links that use the other suffixes, and rooting them all out will take a while.
In that case, you might want a rewrite rule like this:
RewriteRule ^(.*)\.s?html?$ $1.html [NC]
By applying this to subrequests too, you ensure that your Server Side Includes don't break because of the renaming.
Related
I want to remove numbers on the end url in specified folder, using htaccess.
(Numbers and minus sign befor numbers). For all urls in this folder.
For example
http://www.example.com/music/new-track-released-52
or
http://www.example.com/music/helo-there-4
Need to look like
http://www.example.com/music/new-track-released
http://www.example.com/music/helo-there
For all links in folder music
(I'm already removed php extension with htaccess)
How to do that?
Probably something like this:
RewriteEngine on
RewriteRule ^/music/(.+)-[0-9]+$ /music/$1
Note that this is the version for the host configuration. For .htaccess style files this has to be slightly modified. Whenever possible you should prefer not to use .htaccess style files but the real host configuration instead. Those files are notoriously error prone, hard to debug and really slow the server down.
I've a pretty large htaccess about 400 lines and 30 of theme are filled with "RewriteEngine on" do I really have to place it every time before a script or is one time in the first line of the htaccess enough?
Thanks, Sake
As long as it's in the same scope as the rest of your rules, you only need it once, and it doesn't even need to be at the very top.
By scoping, I mean:
<Files "*.php">
RewriteEngine On
(some rules)
</Files>
(some more rules)
isn't going to work, because if the request isn't for a PHP file, the RewriteEngine On isn't going to get applied, and the "some more rules" part won't do anything.
So I usually want to set htaccess rules slightly differently based on what server it is on, eg live or development.
The ErrorDocument usually needs to be different, as well as some of the AddType and SetHandlers bits.
Is there any way I can make this a bit more dynamic and get it to auto detect based on the URL, then set a variable and have if conditionals further down in the htaccess?
Want to do this entirely from URL detection instead of setting parameters with apache please :)
No there isn't any way to set those things via some url detection. You can't make normal if conditions surrounding some of the things you want (AddType SetHandlers and ErrorDocument).
You could use env variables and mod rewrite but I don't think you'll like the end result. You'll have to do something like this using env|E=[!]VAR[:VAL] syntax
If you were in the httpd.conf or vhost file you might be able to separate your different setups by using <directory> sections </directory>. But Directory is not allowed in htaccess.
Also I wouldn't do this in a production environment anyways since something could go wrong and I would think the detection is slower and not needed. Perhaps you may want to look into a build script you run to create/deploy your different setups for development/production depending on hostname and other factors.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
Now that my feet are officially wet with .htaccess I have a new question. In one of the many tutorials I have bookmarked, the author recommends placing this bit of code at the beginning of the .htaccess file:
AddDefaultCharset UTF-8
RewriteEngine On
RewriteBase /
I can understand the issues of avoiding parsing issues with that first line, so what I want to know is, aside from RewriteEngine On are the other two lines good practice or just adding bloat?
Many thanks!
The RewriteBase / line is sometimes used to resolve relative URIs in the target and/or patterns of RewriteRule's. For example, if an htaccess file is in the /foo directory, and you have rules that might look something like this:
RewriteEngine On
RewriteBase /foo/
RewriteRule ^bar$ index.php?bar [L]
Here, the rule's target index.php?bar is a relative URI and the base gets prepended to it, resulting in the URI: /foo/index.php?bar. When the rule's target is relative, apache will make a guess as to whether the URI is a file-path or a URL-path, and it doesn't always guess correctly. With the RewriteBase /foo/, apache knows that the /foo/index.php is a URL-path. There could be instances where the rewrite base doesn't match the folder that it's in, but the result is still the same. It acts as a URI base for the relative URI's that are in the rules.
Having it doesn't hurt, unless for some reason you want certain relative URI's to actually map to file-paths.
The AddDefaultCharset directive doesn't apply to the character set of the htaccess file, it's part of the response that the webserver gives to requests when the requested content is of type text/html or text/plain. Again, doesn't hurt to have this in your htaccess file unless you're text or html content is actually some other encoding (like *shift_jis* for example).
My server is Case Sensitive, and id like to turn it to inSensitive.
Example of what I mean is
lets say I upload Fruit.php
Well then going to this file wont work:
www.website.com/fruit.php
but this one will:
www.website.com/Fruit.php
Is there a way so Fruit.php and fruit.php will work? also with the directories. i.e:
/Script/script.php
/script/Script.php
You need to use the mod_speling (sic) apache module:
http://httpd.apache.org/docs/1.3/mod/mod_speling.html
In .htaccess
<IfModule mod_speling.c>
CheckCaseOnly On
CheckSpelling On
</IfModule>
The CheckSpelling operative makes Apache perform a more involved effort to find a match e.g. correcting common spelling mistakes
Case sensitivity depends on the file system, not Apache. There is a partial solution, however. mod_rewrite can coerce everything to lowercase (or uppercase) like so:
RewriteMap tolowercase int:tolower
RewriteRule ^(.*)$ ${tolowercase:$1}
Reference: http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewritemap
Unfortunately, this only works if all your files are lowercase, while you specifies mixed case filenames (Fruit.php.) Are you comfortable renaming all the files in your project lowercase?
UNIX-servers are case-sensitive - they distinguish between upper-case and lowercase letters in file names and folder names. So if you move your website from a windows to a UNIX-server (when you change web host for instance), you risk getting a certain amount of "Page not found"-errors (404 errors), because directories and other websites linking to yours sometimes get the cases wrong (typically writing the first letter of folder names in upper-case etc.). This javascript-based custom 404-error page solves the problem by converting URL's into lowercase.
You can get the script from http://www.forbrugerportalen.dk/sider/404casescript.js
Happy coding !!!!!!!