I usually put my mod_rewrite conditions in an .htaccess file, but this is a case where it must go into the httpd.conf file.
I am confused because what I want to do seems simple:
The root of the site is a nested directory: mydomain.com/foo/bar/
It just has to be that way.
I want to write a rule so a person can enter:
mydomain.com/simple and it will show content from mydomain/foo/bar
Also, if a person clicks around the site, I want the mydomain.com/simple/some-other-page structure to persist.
The closest I've gotten is this:
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule ^simple$ /foo/bar/$1 [PT]
</IfModule>
However, using this rule, when a person types mydomain.com/simple it rewrites the URI in the browser to mydomain.com/foo/bar
What am I doing wrong?
Thanks in advance.
First, there may be a problem with this rule:
RewriteRule ^simple$ /foo/bar/$1 [PT]
The expression ^simple will probably never match, since all requests will start with a /.
You're using $1 in the right-hand side of the rule, but there are no match groups in the left-hand side that will populate this. This means that a request for /simple would get you /foo/bar/, but a request for /simple/somethingelse wouldn't match the rule. If this isn't the behavior you want, you probably mean this:
RewriteRule ^/simple(.*)$ /foo/bar$1 [PT]
(Note that I've added the missing leading / here as well).
With these changes in place, this rule behaves on my system as I think you're expecting.
Lastly, turning on the RewriteLog and setting RewriteLogLevel (assuming a pre-2.4 version of Apache) will help expose the details of exactly what's happening.
Related
I want to use multiple RewriteRules in .htaccess to modify a single URL, but only the last rule gets applied.
Example INPUT (link loaded by a browser):
http://example.com/aaa/foo/bar
.htaccess:
RewriteRule ^(.*)foo/(.*)$ $1nofoo/$2
RewriteRule ^(.*)bar(.*)$ $1nobar$2
EXPECTED OUTPUT (what Apache should actually look at):
http://example.com/aaa/nofoo/nobar
ACTUAL OUTPUT:
http://example.com/aaa/foo/nobar/
As you can see, only the last rule was applied. Is there any way to make it work the way I want? All suggestions are welcome.
PS. I want to avoid creating a static, ugly rule like
^(.*)foo/bar(.*) $1nofoo/nobar$2
I need all the modifications to work independently of each other.
UPDATE
So here is exactly what I am trying to achieve. I have some links to a backend server:
http://myserver.com/api/user/$userid/car/$carid/getSpeedRecordDetails
http://myserver.com/api/user/$userid/getUserDetails
http://myserver.com/api/car/$carid/getCarDetails
Where $userid and $carid are some unique 12-char-long strings.
And I want to transform them to these:
http://myserver.com/api/getSpeedRecordDetails.php?userid=$userid&carid=$carid
http://myserver.com/api/getUserDetails.php?userid=$userid
http://myserver.com/api/getCarDetails.php?carid=$carid
And I want to achieve it using the least RewriteRules possible (I am looking for a dynamic solution).
UPDATE #2
I love the SO community! Your patience and willingness to help is truly amazing :)
So the very reason why I am interested in modifying the URL using multiple RewriteRules is because I expect that my backend might soon need to implement hundreds (if not thousands) of user-friendly URLs, and mapping all of them individually would be a waste of time and money. Therefore, I want to take advantage of the fact that all the user-friendly URLs consist of repetitive chunks that can be easily translated. The calls below represent the general three types of the user-friendly URLs I need to manage. The only difference within each type is $userid, $carid, and XXXX_of_a_thousand_functions.
http://myserver.com/backend-api/user/$userid/car/$carid/first_of_a_thousand_functions.do
http://myserver.com/backend-api/user/$userid/second_of_a_thousand_functions.do
http://myserver.com/backend-api/car/$carid/sixteenth_of_a_thousand_functions.do
All of these calls (and remember, there will be hundreds, or even thousands of them) need to be translated into these:
http://myserver.com/backend-api/first_of_a_thousand_functions.php?USER_ID=$userid&CAR_ID=$carid
http://myserver.com/backend-api/second_of_a_thousand_functions.php?USER_ID=$userid
http://myserver.com/backend-api/sixteenth_of_a_thousand_functions.php?CAR_ID=$carid
Seeing that there is a simple pattern governing the translation (I hope it is also visible to you), I thought I could create some simple rules for translating different 'chunks' of the user-friendly URL into the internal URL. For example:
RewriteRule ^(.*)user/([A-Za-z0-9]+)/(.*)$ $1$3&USER_ID=$2
Would be responsible for translating the piece user/HSGRE8563LOS into &USER_ID=HSGRE8563LOS
And because some calls have more than one 'chunk' to process, I need to be able to use multiple RewriteRules on a single URL, which I hope somewhat correlates with the title of the question :)
UPDATE #3 - a future reference
So there are a couple of things I believe need to be said regarding this question.
Apparently .htaccess DOES by default apply all the rules that the conditions of are met. However, some CGI/Fast-CGI installations ruin it, resulting in the kind of behaviour depicted in the first example.
Also, one thing I have NEVER seen mentioned anywhere is that Apache applies the RewriteRules not in the order in which they are listed in .htaccess, but it starts 'scanning' the URL from its beginning, and as soons as the conditions for ANY of the rules are met, the URL gets modified accordingly.
After UPDATE#1... to internally rewrite from the stated friendly URLs using mod_rewrite. Try the following directives in the root .htaccess file:
RewriteEngine On
# http://myserver.com/api/user/$userid/car/$carid/getSpeedRecordDetails
RewriteRule ^api/user/(\w{12})/car/(\w{12})/(getSpeedRecordDetails)$ /api/$3.php?userid=$1&carid=$2 [L]
# http://myserver.com/api/user/$userid/getUserDetails
RewriteRule ^api/user/(\w{12})/(getUserDetails)$ /api/$2.php?userid=$1 [L]
# http://myserver.com/api/car/$carid/getCarDetails
RewriteRule ^api/car/(\w{12})/(getCarDetails)$ /api/$2.php?carid=$1 [L]
\w{12} matches a 12 char long string of letters (upper/lower), numbers and underscore. However, this should be made as restrictive as possible. eg. if a valid id is only numeric then \d{12} would be preferable.
UPDATE#2 The process is almost the same as above....
RewriteBase /backend-api
# http://myserver.com/backend-api/user/$userid/car/$carid/<any>.do
RewriteRule ^backend-api/user/(\w{12})/car/(\w{12})/(\w+)\.do$ $3.php?USER_ID=$1&CAR_ID=$2 [L]
# http://myserver.com/backend-api/user/$userid/<any>.do
RewriteRule ^backend-api/user/(\w{12})/(\w+)\.do$ $2.php?USER_ID=$1 [L]
# http://myserver.com/backend-api/car/$carid/<any>.do
RewriteRule ^backend-api/car/(\w{12})/(\w+)\.do$ $2.php?CAR_ID=$1 [L]
Note the use of RewriteBase. This allows the URL-path to be removed from the RewriteRule substitution.
If /backend-api exists as a physical directory then these rules could instead go in /backend-api/.htaccess. Then you could remove the RewriteBase directive and modify the RewriteRule pattern by removing the backend-api/ portion from near the start of the pattern.
UPDATE#3 - a future reference
Apparently .htaccess DOES by default apply all the rules that the conditions of are met. However, some CGI/Fast-CGI installations ruin it, resulting in the kind of behaviour depicted in the first example.
There are certainly some server (mis)configurations that appear to affect certain aspects of .htaccess/mod_rewrite, however, not in the way suggested earlier in your question and I have never encountered this directly myself. And this should have nothing to do with CGI/Fast-CGI. (?)
...Apache applies the RewriteRules not in the order in which they are listed in .htaccess, ...
Not sure exactly what you mean by this, but RewriteRules are processed "in the order in which they are listed in .htaccess" - this is fundamental to how mod_rewrite works. (However, different modules execute at different times, regardless of the order in .htaccess, but within each module the directives execute top-down, in order. eg. mod_rewrite executes before mod_alias (usually), so if you have a mod_alias Redirect before a mod_rewrite RewriteRule, the RewriteRule is still processed first - which is why it is a bad idea to mix redirects from both modules, as you can end up with confusing conflicts.)
...but it starts 'scanning' the URL from its beginning, and as soons as the conditions for ANY of the rules are met, the URL gets modified accordingly.
Exactly, in the order in which they appear in the file.
Note that it's the RewriteRule directives that are scanned (top - down), not the conditions (ie. RewriteCond directives) - in case that is what you were implying. If the RewriteRule pattern matches the URL-path then the preceding RewriteCond directives are processed and if all these pass then the substitution occurs. (Which is why it is always more efficient to match what you can with the RewriteRule and not rely totally on the RewriteCond directives - the RewriteRule is processed first, not the RewriteCond directives.)
Crucially, (and this might be where you are tripping up?), is that if you have multiple RewriteRule directives then the following RewriteRule directives match against the output/substitution of the previously matched RewriteRule (if any), not against the URL-path of the initial request. Only the first matched RewriteRule matches against the URL-path of the request. So, yes, RewriteRule directives do chain together.
The exception to this is the L (LAST) flag on the RewriteRule. This "breaks" the chain. Although not completely... it causes the current round of processing to stop, but then it all starts again from the top! Only when the URL passes through unchanged is processing finished. (However, in Apache 2.4 you do have the END flag - this does indeed halt processing completely.)
I've got an .htaccess rule like this:
RewriteRule ^z/([^/]+)$ y.html?$1 [NC,L]
This rule works fine. But if I change the rule slightly, to:
RewriteRule ^y/([^/]+)$ y.html?$1 [NC,L]
When I try to load y/anything I get a 404 and the following message in the error log:
File does not exist: /var/www/y.html/anything
The only difference I can see is that z.html does not exist, but y.html does. At first I thought maybe the initial transform was triggering a recursive re-write, but I don't see how this could be. It should rewrite:
`y/anything`
to
`y.html?anything`
Which does NOT have a slash in it. In fact, the only problem with the re-written URL is that it has a slash where I specified a question mark. What is going on here?
It gets stranger. If I change the rewrite URL, e.g. to
RewriteRule ^y/([^/]+)$ /q.html?$1 [NC,L]
it STILL is telling me /var/www/y.html/anything not found, not q.html..
If I move y.html to y.js on the server, then it tells me /var/www/y.js/anything is not found. It really seems like it is somehow matching /dir/ and changing it to an existing file. Is there a default rule somewhere in apache that might do this?
I tried a hard reload in the browser, which had no effect.
Update: I tried to use RewriteLog to see what was going on with the re-writing. However, to do this I had move my rewrite entries to the VirtualHost section of my main config. After I did this the pattern matching completely stopped until I changed my rule to:
RewriteRule ^/y/([^/]+)$ /y.html?$1 [NC,L]
After making this change, everything works as expected. So why can't I get it to work in the .htaccess file? Neither regex works properly there (with or without the leading slash).
For anyone who runs into this problem in the future, the issue I was having was that MultiViews was interfering with my URL resolution. When I removed "MultiViews" from the list of options for the <Location/> in the <VirtualHost> the issue went away.
Having the following in the htaccess file
RewriteEngine On
RewriteRule ^z/([^/]+)$ /y.html?$1 [NC,L]
RewriteRule ^y/([^/]+)$ /y.html?$1 [NC,L]
will show the contents of y.html
You might want to do a hard refresh of the page because if it was previously redirected to /y.html/anything, but then changed to /y.html?anything it might still be in a cache on your browser. Double check with your other browsers that the same thing is happening on them.
I'm having some trouble with Apache's mod_rewrite. One of the things I'm trying to get it to do is hide some of my implementation details, so that, for example, the user sees the URL http://www.mysite.com/login but Apache responds with the page at http://www.mysite.com/doc_root/login.php instead (preferably without showing the user that it's a PHP file or the directory structure). Here's what I have in my .htaccess file:
RewriteEngine on
RewriteCond %{HTTP_HOST} ^(www.)?mysite.com*
RewriteRule ^/(\w+) /doc_root/$1.php [L]
#Redirect http://www.mysite.com to the login page
RewriteRule ^/?$ https://www.mysite.com/doc_root/login.php
But when I go to http://www.mysite.com/login, I get a 404 error even though the page exists. I clearly don't have a great understanding of how the mod_rewrite conditionals and rules work, so can anyone please tell me what I'm doing wrong? Thanks.
Take doc_root out of all the stuff you have it in. That will give you the result you're asking for. However I'm not sure if it's desired or not. How are you going to force someone to login if they manually type http://www.mysite.com/index.php?
Also if you're trying to force all traffic to SSL it's better to use a second VirtualHost and Redirect instead of mod_rewrite. Those are all questions probably better suited for ServerFault
Unless your site has a bunch of different domain names, and you only want mysite.com to do the rewriting, you don't need the RewriteCond. (Potential problem. Apache likes to dick around with the domain name unless you set UseCanonicalName off. If the name isn't what it's expecting, the rewrite won't happen.)
In RewriteCond (and RewriteRule) patterns, . matches any character. Add a backslash before them. (Minor bug. Shouldn't cause rewrites to fail, but they would match stuff like "mysite-com" as well.)
mod_rewrite is actually a URL-to-filename filter. Though it is often used to rewrite URLs to other URLs, sometimes it will misbehave if what you're rewriting to is a URL and it can't tell. (Especially if what it's rewriting to would be an alias, or would otherwise not translate directly to a real filename.) If you add a [PT] flag onto your rule, though, it will consider the rewritten thing a URL and pass it along to the other filters (including the ones that turn URLs into filenames).
Do you really need "/doc_root"? The document root should already be set up in Apache using the DocumentRoot directive, and shouldn't need to be part of the URL unless you have multiple apps on the same domain (in which case it's the app root; the document root doesn't change).
UPDATE:
Another thing i just thought about: Rewrite rules work differently in .htaccess files. Apache likes to strip off the leading slash. So you will probably want to get rid of the first slash in your patterns, or at least make it optional (^/?login instead of ^/login).
^/?(\w+) will match /doc_root/login.php, and cause a rewrite to /doc_root/doc_root.php. You should probably have a $ at the end of your pattern.
The web server is Apache. I want to rewrite URL so a user won't know the actual directory. For example:
The original URL:
www.mydomainname.com/en/piecework/piecework.php?piecework_id=11
Expected URL:
piecework.mydomainname.com/en/11
I added the following statements in .htaccess:
RewriteCond %{HTTP_HOST} ^(?!www)([^.]+)\.mydomainname\.com$ [NC]
RewriteRule ^(w+)/(\d+)$ /$1/%1/%1.php?%1_id=$2 [L]
Of course I replaced mydomainname with my domain name.
.htaccess is placed in the site root, but when I access piecework.mydomainname.com/en/11, I got "Object not found".(Of course I replaced mydomainname with my domain name.)
I added the following statements in .htaccess:
RewriteRule ^/(.*)/en/piecework/(.*)piecework_id=([0-9]+)(.*) piecework.mydomainname.com/en/$3
Of course I replaced mydomainname with my domain name.
.htaccess is placed in the site root, but when I access piecework.mydomainname.com/en/11, I got "Object not found".(Of course I replaced mydomainname with my domain name.)
What's wrong?
Try using RewriteLog in your vhost or server-conf in order to check the rewriting process. Right now you just seem to guess what mod_rewrite does.
By using RewriteLogLevel you can modify the extend of the logging. For starters I'd recommend level 5.
PS: Don't forget to reload/restart the server after modifying the config.
Here's a quick overview of what's happening:
RewriteCond %{HTTP_HOST} ^(?!www)([^.]+)\.mydomainname\.com$ [NC]
First, the question mark is supposed to be at the end.
$1 would (should) match anything that is not 'www' 0 or 1 times.
$2 matches anything that is not a character 1 or more times, which theoretically would match a blank space there but likely would never match anything.
Then it requires '.mydomainname.com' after those two groupings.
Your first two conditions are looking for two separate groupings.
I'm not sure exactly how you're trying to set up your structure, but here is how I would write it based on your original and expected URL's:
RewriteCond %{HTTP_HOST} !^www\.mydomainname\.com$ [NC]
RewriteCond %{HTTP_HOST} ^(\w+)\.mydomainname\.com$ [NC]
RewriteRule ^(\w+)/(\d+)$ /$1/%1/%1.php?%1_id=$2 [L]
Basically, your first condition is to make sure it's not the URL beginning with 'www' (it's easier to just make it a separate rule). The second condition makes it check any word that could possibly be in front of your domain name. Then your rewrite rule will redirect it appropriately.
Get rid of the last .htaccess line there in your question...
Someone please correct me if I typed something wrong. I don't remember if you have to have the '\' in front of '\w' and '\d' but I included them anyways.
You are doing it backwards. The idea is that you will give people the friendly address, and the re-write rule will point requests to this friendly, non-existent page to the real page without them seeing it. So right now you have it only handling what to do when they go to the ugly URL, but you are putting in the friendly URL. since no rule exists for when people put the friendly URL directly, apache looks for it and says "Object not Found"
So add a line:
RewriteRule piecework.mydomainname.com/en/(*.) ^/$3/en/piecework/$3?piecework_id=([0-9]+)(.*)
Sorry, that's quite right, but the basic idea is, if they put in the URL you like, Apache is ready to redirect to the real page without the browser seeing it.
Update
I'm way to sleepy to do regex correctly, so I had just tried my best to move your example around, sorry. I would try something more simple first just to get the basic concept down first. Try this:
RewriteRule www.mydomainname.com/en/piecework/piecework\.php\?piecework_id\=11 piecework.mydomainname.com/en/11
At the very least, it will be easier to see what isn't working if you get errors.
I hope I can explain this clearly enough, but if not let me know and I'll try to clarify.
I'm currently developing a site using ColdFusion and have a mod_rewrite rule in place to make it look like the site is using PHP. Any requests for index.php get processed by index.cfm (the rule maps *.php to *.cfm).
This works great - so far, so good. The problem is that I want to return a 404 status code if index.cfm (or any ColdFusion page) is requested directly.
If I try to block access to *.cfm files using mod_rewrite it also returns a 404 for requests to *.php.
I figure I might have to change my Apache config rather than use .htaccess
You can use the S flag to skip the 404 rule, like this:
RewriteEngine on
# Do not separate these two rules so long as the first has S=1
RewriteRule (.*)\.php$ $1.cfm [S=1]
RewriteRule \.cfm$ - [R=404]
If you are also using the Alias option then you should also add the PT flag. See the mod_rewrite documentation for details.
Post the rules you already have as a starting point so people don't have to recreate it to help you.
I would suggest testing [L] on the rule that maps .php to .cfm files as the first thing to try.
You have to use two distinct groups of rewrite rules, one for .php, the other for .chm and make them mutually exclusives with RewriteCond %{REQUEST_FILENAME}. And make use of the flag [L] as suggested by jj33.
You can keep your rules in .htaccess.