I have a hosted website where I use the following htaccess file for formatting of urls, These all work fine. The host uses Apache, but unfortunately doesn't show a version number. I think it's 2.4.
Options +FollowSymLinks
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
RewriteRule ^item/([0-9]+)/(.*) /item.php?item=$1&title=$2 [L]
RewriteRule ^category/(.*) /showitems.php?category=$1 [L]
RewriteRule ^search/(.*) /searching.php?options=$1 [L]
RewriteRule ^searching/(.*) /showitems.php?search=$1 [L]
RewriteRule ^update/(.*) /showitems.php?update=$1 [L]
AddType application/x-httpd-lsphp .html .htm .shtml
I copied the entire site to my local Synology Diskstation with Apache 2.4.
The rewrite urls for category, search and update work fine. However, the urls for 'searching' and 'item' return 404 errors. 'Searching' is a header redirect from within 'searching.php'
Item is an oddity in the sense that it uses 2 get params in the result url. In trial and error mode I changed it to:
RewriteRule ^item/(.*) /item.php?item=$1 [L]
Which doesn't work either, however
RewriteRule ^itemitem/(.*) /item.php?item=$1 [L]
Works fine, which really puzzles me. This last rewrite also doesn't work when I add the second parameter again.
What am I missing? Or is there a better way to approach these rewrites in the first place that I could try?
What CBroe has commented on your post is properly the correct answer.
To be more specific and explain why then if your Apache 2.x server has MultiViews enabled it will try to match things up for you like directory names, file names on your behalf to make the user-experience easier.
However, this can in many cases confuse your rewrite rules that are expecting very specific regular expressions.
In most cases you can get away with just disabling MultiViews.
You disable it by adding to your Options in your .htaccess file.
-MultiViews
Please note that if the AllowOverrive directory does not allow this then your need to change the Apache configuration file for that vhost/directory to include the -MultiViews option.
You can read more about MultiViews here:
http://httpd.apache.org/docs/current/content-negotiation.html
The other thing and perhaps more correct way is to build your rewrite rules better and take advantage of things like the "!-f" or "!-d" parameter to let your rules know that you don't want to include files or directories and so forth.
A side note by the way on MultiViews, even though it's very fancy and neato - If you are running a production site please know that MultiViews create a hole lot of unwanted disk I/O and can slow down the Apache servers performance quite a bit! So it's always good practice to disable MultiViews.
Related
I've never been good at .htaccess, I'm trying to copy and paste some code that worked on another one of my domains and modify it to work here. I will have several rewritten URLs, some static, some dynamic, but I can't even get the simplest of them to work. This one is testable here: http://lindseymotors.com/home
Clearly, index.php is available because if you access http://lindseymotors.com it works.
RewriteEngine On
RewriteCond %{HTTP_HOST} ^.* [NC]
RewriteRule ^home$ index.php
RewriteRule ^home/$ index.php
# When answering, if you could write a statement that would combine
# both of the statements above into one that would be appreciated.
As I said, these same conditions worked on another one my domains because I copied the code right over. I asked my server admin to double check everything on his end and it was fine. Any ideas?
Only thing I can think of is make sure the use of .htaccess is really on. The easiest way you can check since your server admin says it's fine is to put random text at the top of your .htaccess file. If your .htaccess file is being read and .htaccess files are enabled, it should throw a 500 internal server error. If not, then they don't have .htaccess files enabled and need to add AllowOverride All to the Apache config vhost.
Here is your rule combined into one as you noted. You really don't need the RewriteCond, but I will leave since you were using it previously.
RewriteEngine On
RewriteCond %{HTTP_HOST} ^.* [NC]
RewriteRule ^home/?$ index.php [L]
I would like to rewrite files that don't exist to a php handler. I am currently using this .htaccess file, but it doesn't work as I'd like:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /app/index.php?_url=/$1
When I have no files, it works; it redirects correctly for resource that does not exist to my app, and I am able to capture it.
When I have exactly matching file (e.g.: test.txt and I request /test.txt); it loads test.txt correctly.
However, when I have a partial match (e.g.: test.txt exists, but I request /test); it does not redirect at all. In fact, it gives me the standard Apache 404. I want this to actually rewrite to my app, so I can deal with the request in a different manner.
I'm using pretty much default apache 2.2.22 from Debian. Is there some configuration I am missing, or is this the intended behaviour of the rewrite? Is there a way to achieve what I want?
I think you have MultiViews enabled in your Apache by default. Try adding this line on top of your .htaccess:
Options -MultiViews
With MultiViews Apache does its own rewrites and that usually conflicts with mod_rewrite
In order to redirect all somefolder/index.html (and also somefolder/index.htm) to somefolder/ I use this simple rewrite rule in Apache .htaccess file:
RewriteEngine on
RewriteCond %{THE_REQUEST} ^.*\/index\.html?\ HTTP/
RewriteRule ^(.*)index\.html?$ "/$1" [R=301,L]
This works well!
But at Google groups they suggest to add also:
Options +FollowSymlinks
RewriteBase /
Could anyone be so kind to explain me why would i have to add these last lines, and explain me a bit what they mean and what they do?
Is there a potential secuirty risk in not adding these lines?
Many thanks,
Why they're suggested:
It's suggested that you add Options +FollowSymlinks because it's necessary that symlink following is enabled for mod_rewrite to work, and there's a chance that, while you may be allowed to turn it on, it's not enabled by the main server configuration. I suspect the reason that symlink following is necessary is beause the module makes a number of calls to apr_stat(), which looks like it needs to follow symlinks in order to get file information in all cases.
As for RewriteBase, it's typically not necessary. The documentation goes on about it, but as most people's files do live under the DocumentRoot somewhere, it usually only serves a purpose if you're redirecting externally and you use directory-relative URLs. To illustrate what I mean, consider the following:
RewriteEngine On
RewriteRule ^redirect index.html [R,L]
A request for example.com/redirect will result in an external redirect to example.com/full/path/to/web/root/index.html. The reason for this is that before it handles the redirection, mod_rewrite re-appends the current directory path (which is the default value of RewriteBase). If you modified RewriteBase to be /, then the path information would be replaced with that string, so a request for index.html would now be a request for /index.html.
Note that you could just have done this explicitly on the replace too, regardless of the value of RewriteBase:
RewriteEngine On
RewriteRule ^redirect /index.html [R,L]
...works as intended, for example. However, if you had many rules that needed a common base and were being shifted around between directories, or your content wasn't under the root, it would be useful to appropriately set RewriteBase in that case.
The risk of not using them:
There's absolutely no security risk in not specifying Options +FollowSymlinks, because if you don't and it's not set by the main server configuration, mod_rewrite will always return 403 Forbidden. That's kind of problematic for people trying to view your content, but it definitely doesn't give them any extended opportunity to exploit your code.
Not setting RewriteBase could expose the path to your web content if you had an improperly configured rule set in one of your .htaccess files, but I'm not sure that there's any reason to consider that a security risk.
I noticed an odd (to me) mod_rewrite thing happening. Fixing it is not important to me so much as figuring out what's going on. Basically, I have an svg file called test.svg in my document root, as well as an index.php. My expectation, based on my .htaccess file is that visiting http://localhost/test.svg would get me the .svg file (and it does), while visiting http://localhost/test/action would be rewritten to index.php/test/action. Instead, the latter is apparently rewritten to test.svg/action, as I receive the message
The requested URL /test.svg/action was not found on this server.
Here is my .htaccess file:
# Turn on URL rewriting
RewriteEngine On
# Protect application and system files from being viewed
# RewriteRule ^(application|modules|system) - [F,L]
# Allow any files or directories that exist to be displayed directly
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
# Rewrite all other URLs to index.php/URL
RewriteRule .* index.php/$0 [PT,L]
I am using a Apache 2.2.12 on Ubuntu (installed via apt-get). I think my setup is fairly standard, but I'm not sure exactly what directives or config files would be relevant. I am by no means a sysadmin of any kind, I just use this server to test and develop things locally.
As I said, fixing this issue would be trivial, I just am often confounded by mod_rewrite and would like to understand what's going on here.
Apache's HTTP content negotiation feature is automatically translating from "/test" to "/test.svg". See http://httpd.apache.org/docs/2.0/content-negotiation.html#multiviews
You can disable content-negotiation in .htaccess with the directive:
Options -MultiViews
You can get more information about what mod_rewrite is doing by adding these directives to your Apache configuration (they won't work in .htaccess):
RewriteLog /path/to/rewrite.log
RewriteLogLevel 3
The RewriteLogLevel can be any number from 0 (disabled) to 9 (extremely verbose). 3 should give you enough to see what's going on, but don't use that on a production server.
I am betting on an obvious problem here I am not seeing.
Here's the important bits for those of you familiar with Mod-Rewrite
.htaccess file with mod-rewrite rules exists here:
http://www.thedomain.com/.htaccess
User goes to this URL:
http://www.thedomain.com/test/blog
Mod-Rewrite rules should actually tell the server to access this URL:
http://www.thedomain.com/index.php?page=blog
.htaccess:
Options FollowSymLinks
Options -MultiViews
RewriteEngine on
RewriteRule ^test/([^/.]+)$ /index.php?page=$1 [L]
This combination of code/request does not work. If you're wondering about the code snippet ^test not being ^/test instead, it is because apparently this is a problem on GoDaddy, the code fails with the / after the ^ - this seems like it may be related to my problem, which I'll explain further... If I change the .htaccess code line:
RewriteRule ^test/([^/.]+)$ /index.php?page=$1 [L]
to
RewriteRule ^test([^/.]+)$ /index.php?page=$1 [L]
(just removing the / here: ^test/([^/.]+) )
The code works when the requested URL is changed to accomodate (remove the slash; http://www.thedomain.com/testblog) as the user views the proper index.php?page=blog server response. It seems to me I cannot use any slashes within the darn match side of the RewriteRule. What gives?
Update: If at all relevent, this .htaccess file and the relevant files to the question all exist in a subdirectory off of the GoDaddy server that is hosting this although the domain points to the subdirectory as the root. Not sure if this is relevant.
Update: This server (at the server root) is actually running wordpress with pretty URLs enabled and they work perfectly fine. I assume wordpress uses mod-rewrite to make crazy urls like thedomain.com/2008/11/15/the-article-title.html work...?
Thanks so much.
Is RewriteBase what you're looking for?
there is a nice test utility for windows here
http://www.helicontech.com/download-isapi_rewrite.htm
try changing your code to:
^/test/([^/]+)$ /index.php?page=$1 [L]
or without slashes
^test[^a-z]+([a-z]*)$ /index.php?page=$1 [L]
I was unable to find a solid method around this problem on GoDaddy; for whatever reason I could not have slashes within the URL that was attempting to be rewritten aside from the base (http://www.somedomain.com/testingthis would work but http://www.somedomain.com/testing/this died).
I ended up instead using the Wordpress .htaccess to send all non-existant file/directory requests back to my index.php. I then used the $_SERVER['REQUEST_URI'] var with pathinfo() to parse the URL and then direct what content to load from the parsing. This works well, is fast, and is probably the same method Wordpress uses.
Thanks for the attemps!
If you're wondering about the code snippet ^test not being ^/test instead, it is because apparently this is a problem on GoDaddy, the code fails with the / after the ^ […]
That’s not odd but necessary:
Per-directory Rewrites
When using the rewrite engine in .htaccess files the per-directory prefix (which always is the same for a specific directory) is automatically removed for the pattern matching and automatically added after the substitution has been done.
And that per-directory prefix is for a .htaccess file in the document root (/.htaccess) the URL path root (/). Thus patterns with the ^ must be written without that per-directory prefix /.
On the same way the substitution is handled. After a rule is applied, the per-directory prefix is added to the substituion. So try this rule:
RewriteRule ^test/([^/.]+)$ index.php?page=$1 [L]
OK, first off, I think that the GoDaddy apache server simply has some of the options turned off. I think that if they don't have an AllowOverride FileInfo in their configuration, RewriteRule won't work so well, or at all.
Which means its surprising that the URL http://www.thedomain.com/testblog works at all, and gets re-written. So I guess I'm a little confused.
Here's an idea: Try creating a directory named test, and put the .htaccess file in there! It would look like this:
Options FollowSymLinks
RewriteEngine on
RewriteRule ^([^/]+)$ /index.php?page=$1 [L]
OK, another idea: Use RewriteCond. Maybe you can check the request URI directly, like this:
Options FollowSymLinks
RewriteEngine on
RewriteCond %{REQUEST_URI} ^/test/([^/]+)
RewriteRule . /index.php?page=%1 [L]
Last idea: maybe your browser sees the URL http://www.thedomain.com/test/blog and thinks it's a directory, and adds a slash? So the URL is sends is http://www.thedomain.com/test/blog/. In that case, the REGEX won't match unless you allow for a trailing slash:
RewriteRule ^test/([^/.]+)/?$ /index.php?page=$1 [L]
Whoops. Sorry for gushing - there's just some many things that can go wrong in an HTTP request that goes through rewriting, and as many ways to try and overcome the problems :-)