My Apache2.2 seems to work like this: when I request www.site.com/name first it is looking for folder /name/, if not found, next it is searching for file name.php.
But when I turn on RewriteEngine On in .htaccess and add RewriteRule ^name$ name2.php, then Apache still will be looking if there is folder or file name in spite of RewriteRule.
How can I give RewriteRule priority?
I found solution here http://httpd.apache.org/docs/2.2/content-negotiation.html - "Negotiation in Apache" section, "Multiviews" subtitle:
The effect of MultiViews is as follows: if the server receives a request for /some/dir/foo, if /some/dir has MultiViews enabled, and /some/dir/foo does not exist, then the server reads the directory looking for files named foo.* (...)
So in my case (I use mod_userdir), I edited /etc/apache2/mods-enabled/userdir.conf
<IfModule mod_userdir.c>
(...)
<Directory /home/*public_html>
(...)
#Options MultiViewes # I COMMENTED OUT THIS OPTION
</Directory>
</IfModule>
Now if I request www.domain.com/foo apache won't search for file named foo in directory! And from now on RewriteRule ^name$ another-name.php will work.
Related
I'm trying to setup Apache to rewrite particular file names when requested under a virtual host. The goal is to change certain branding elements based on the host header used (all of which have virtual host configs).
I had this working in nginx as per the example below
if ($host = "test.example.com") {
rewrite ^/images/file1.png$ /images/otherfile1.png;
rewrite ^/images/file2.png$ /images/differentfile2.png;
break;
}
For Apache I used the following config in the virtual hosts file, and confirmed the module is running, but it does not seem work (the original file1 is used).
<Directory "/opt/site/html/">
AllowOverride All
Options FollowSymLinks MultiViews
Require all granted
RewriteEngine On
RewriteBase /
RewriteRule ^/images/file1.png$ /images/otherfile1.png
RewriteRule ^/images/file2.png$ /images/differnetfile2.png
</Directory>
Any advice on what I'm missing to enable this rewrite would be greatly appreciated.
RewriteRule ^/images/file1.png$ /images/otherfile1.png
RewriteRule ^/images/file2.png$ /images/differnetfile2.png
These directives are inside a <Directory> container (inside a <VirtualHost>). In a directory context (as with .htaccess), the URL-path matched by the RewriteRule pattern does not start with a slash. So the above rules will not match. The directives should be like this instead:
RewriteRule ^images/file1\.png$ /images/otherfile1.png [L]
RewriteRule ^images/file2\.png$ /images/differnetfile2.png [L]
NB: Don't forget to backslash-escape literal dots in the regex and you should use the L flag here to stop further processing by the rewrite engine.
Alternatively, you can move these rules out of the <Directory> wrapper and into the <VirtualHost> container directly. In this context, the rules match against the full root-relative URL-path, starting with a slash (as you have written). But in a virtualhost context, the RewriteBase directive is not permitted so must be removed (you are not making use of this anyway).
Aside:
AllowOverride All
Options FollowSymLinks MultiViews
You are allowing .htaccess overrides (first directive). Note that if you do have an .htaccess file with mod_rewrite directives (RewriteRule etc.) then these will completely override the directives in the corresponding <Directory> container in the server config. You may want to explicitly disable .htaccess overrides, for example:
AllowOverride None
You've also enabled MultiViews - is that intentional? This basically enables extensionless URLs out-of-the-box (on everything) and can potentially conflict with mod_rewrite, so generally, this should be disabled. Simply remove it from the above rule to disable this, for example:
Options FollowSymLinks
RewriteBase /
You're not actually using this in the directives you've posted.
There are some PHP files on an external drive which is mapped to the Z: drive on a Windows 10 machine. This code is in the httpd-vhosts.conf Apache file:
<VirtualHost *:8080>
DocumentRoot "Z:/files/xampp/htdocs"
<Directory "Z:/files/xampp/htdocs">
Options Indexes
Require all granted
</Directory>
</VirtualHost>
The task at hand is to allow .htaccess overrides for a file path within the path shown above. In the httpd.conf file the rewrite module is enabled. That line looks like this: LoadModule rewrite_module modules/mod_rewrite.so. I tried adding this code to the httpd.conf file:
<Directory "Z:/files/xampp/htdocs/miscellaneous/WebServiceExamples">
AllowOverride All
</Directory>
The Apache web server was stopped and restarted after making these changes. The code in .htaccess looks like this:
<IfModule mod_rewrite.c>
# turn rewrite engine on
Options +FollowSymlinks
RewriteEngine on
# map neat URL to internal URL
RewriteRule ^mobile/list/$ RestController.php?view=all [nc,qsa]
RewriteRule ^mobile/show/([0-9]+)/$ RestController.php?view=single&id=$1 [nc,qsa]
</IfModule>
However, when a URL that should be handled by the rewrite rule in the .htaccess file is entered in the Chrome address bar the result is an Object not found! Error 404. Where did I go astray?
EDIT:
Another thing I tried was putting httpd.conf back to its original state, then modifying httpd-vhosts.conf as follows:
<VirtualHost *:8080>
DocumentRoot "Z:/files/xampp/htdocs"
<Directory "Z:/files/xampp/htdocs">
Options Indexes
Require all granted
</Directory>
<Directory "Z:/files/xampp/htdocs/miscellaneous/WebServiceExamples">
AllowOverride All
</Directory>
</VirtualHost>
After stopping and restarting the Apache web server, the result is still the same as before:
Object not found! Error 404.
Figured this out. The configuration files were left in the state as described in the Edit section in the original post. The Troubleshooting section in this link was a helpful guide for determining that the configuration files were set up correctly.
This was entered as the URL in Chrome's address bar: http://localhost:8080/miscellaneous/WebServiceExamples/SimpleRestfulWebService/mobile/list. Notice there is no trailing forward slash. The rewrite rule was in .htaccess was written in such a way that made a trailing forward slash mandatory. When the rewrite rule lines were modified to make the trailing slash optional, then it worked fine. Here are the modified rewrite rules:
RewriteRule ^mobile/list/?$ RestController.php?view=all [nc,qsa]
RewriteRule ^mobile/show/([0-9]+)/?$ RestController.php?view=single&id=$1 [nc,qsa]
Trying to fix this .htaccess, so it can work on a SSL apache server. Before it was hosted on another Linux server (http://) and was working without problems, but when uploading the files to another Linux server with apache and SSL (https://), it stopped working. The main function is to hide the .php extension...
Here´s what I was using:
Options +FollowSymLinks -MultiViews
# Turn mod_rewrite on
RewriteEngine On
RewriteBase /
# To externally redirect /dir/foo.php to /dir/foo
RewriteCond %{THE_REQUEST} ^[A-Z]{3,}\s([^.]+)\.php [NC]
RewriteRule ^ %1 [R,L,NC]
## To internally redirect /dir/foo to /dir/foo.php
RewriteCond %{REQUEST_FILENAME}.php -f [NC]
RewriteRule ^ %{REQUEST_URI}.php [L]
Thanks for your help!
So, .htaccess files may not be allowed, and by default on many systems they are not allowed. To see if .htaccess is allowed, make this your .htaccess:
BREAK IT!
That should be the only contents in your .htaccess. Attempt to load any page on your website, and if .htaccess usage is enabled, you would see "Internal Server Error" or possibly some other error, but you would not see your actual page.
If you do see the error, that's actually good and means .htaccess usage is enabled. If you don't see the error, it's likely that you will have to find your Apache .conf file and inside look for the line(s):
AllowOverride None
Change that to:
AllowOverride All
If after doing that you still can't use .htaccess, then there may be other apache related files that have "AllowOverride None". On that comes to mind is your virtual host file, and on my system that is located at /etc/apache2/sites-available/.
If you still have problems, check this out:
https://docs.bolt.cm/3.3/howto/making-sure-htaccess-works
Solution is for the issue, need to change in apache2.conf file after that it will works,
Change this file /etc/apache2/apache2.conf
update it same
OLD:
<Directory /var/www/>
Options Indexes FollowSymLinks
AllowOverride None
Require all granted
</Directory>
New Updated Code:
<Directory /var/www/>
Options Indexes FollowSymLinks
AllowOverride All
Require all granted
</Directory>
I had a similar problem. Apache 2.4.23 with .htaccess error 404 set up.
Using it with HTTP works fine; access it with HTTPS didn't work.
I seted AllowOverride All in the http.conf and error 404 wors well.
In my apache configuration I have a virtual host configured like this:
Alias /mediamanager /storage/files/mediamanager
<Directory /storage/files/mediamanager>
DirectoryIndex /mediaManagerIndex.php
DAV On
# ... And some authentication directives ... #
</Directory>
The idea is that someone can access the files both by a WebDAV-Client and also a simple web browser in which case some pretty directory view is generated by a PHP script.
That worked great in Apache 2.2, but recently I upgraded to Apache 2.4 and now it is broken. I highly suspect I I suffer from this bug which is already 2 years old and no fix in sight. The proposed workaround to add:
<Limit PROPFIND>
DirectoryIndex never-encounterable-file-name.html
</Limit>
Does not work for me. Probably because I still want to have a directory index. If I remove my DirectoryIndex altogether WebDAV works again (no index.html or similar files exists in this directory) but of course I loose the ability to use my PHP file as directory index. I tried to specify my DirectoryIndex in a <Limit GET> but this had no effect.
Is there any way to get both DAV and DirectoryIndex to work simultaneously in Apache 2.4 on Debian (if anyhow possible without changing the source code and recompiling)?
In order to fix this, disable directory indexing for the WebDAV site.
In your sites-available/site.conf file add DirectoryIndex disabled to the <Directory> declaration, like so:
<Directory /path/to/my/webdav/dir>
Options Indexes FollowSymLinks MultiViews
AllowOverride all
Require all granted
DirectoryIndex disabled
</Directory>
Then just reload Apache and you will no longer have that issue:
sudo service apache2 reload
For me, the following configuration solved both problems:
WebDAV works again
directory indexing, if the user uses a web browser to access the repository
It works by manually implementing the directory-indexing feature with simple rewrite rules, which are applied only for the GET request method.
The following code has to be placed inside the server config or virtual host context in the apache configuration file.
# Turn off (automatic) Directory-Indexing
DirectoryIndex disabled
RewriteEngine On
# Rewrite rules for the root directory
RewriteCond "%{REQUEST_METHOD}" "(GET)"
RewriteRule "^/$" "/index.php" [L]
# Rewrite rules for other sub-directories
RewriteCond "%{REQUEST_METHOD}" "(GET)"
# The following line checks, if the index.php file exists
RewriteCond "%{DOCUMENT_ROOT}/$1/index.php" "-f"
RewriteRule "^/(.*)/$" "/$1/index.php" [L]
Don't forget to reload Apache!
This is the solution I am currently using, located in a .htaccess file at the root of the directory tree used by the WebDav service. In this case I do not use PHP, only html files, but it can be easily adapted:
# Turn off automatic directory indexing
Options -Indexes
DirectoryIndex disabled
# Redirect directory requests to index.html, only for GET requests
RewriteEngine On
RewriteCond %{REQUEST_METHOD} "GET"
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^(.*)$ $1index.html [L]
In order to launch always the requested PHP file, just replace "index.html" on the last line by the PHP file name:
RewriteRule ^(.*)$ $1mediaManagerIndex.php [L]
I am relatively new to mod_rewrite, but have a site which I would like to have "pretty urls." Similarly to SO :).
I am attempting to have things like: "http://www.whatever.com/search/test" get rewritten to "http://www.whatever.com/search.php?q=test" and have had some limited success. I believe that content negotiation is getting in my way...
For starters here's my test .htaccess file:
RewriteEngine on
RewriteBase /~user/mysite/
RewriteRule ^search$ search/ [R]
RewriteRule ^search/([^/]*)/?$ search.php?q=$1 [L]
Which unfortunately, does redirect to search.php, but does not pass my param in the q variable. However this does work:
RewriteEngine on
RewriteBase /~user/mysite/
RewriteRule ^search$ search/ [R]
RewriteRule ^search/([^/]*)/?$ s.php?q=$1 [L] # here i've renamed the search.php to s.php to dodge the content negotiation that is happening..
In fact, if I remove the rules all together, I get the same result as with the first version of the file. So my conclusion is that since apache is happily redirecting "foo" to "foo.php" even without any mod_rewrite rules, that it must be the content negotiation that is taking care of it. (This is further verified by the fact if I renamed my foo.php to foo.html, it still will find the file if i just go to "foo").
So, the question is. How do I properly use mod_rewrite with regard to content negotiation? Can I disable it for a particular file? Is there a way to ensure that my mod_rewrite rules happen before the content negotiation happens?
If it is relevant, here is the conf file for the mod_userdir part of my apache conf (this test site is in my user's homedir/public_html):
# Settings for user home directories
<IfDefine USERDIR>
<IfModule userdir_module>
# UserDir: The name of the directory that is appended onto a user's home
# directory if a ~user request is received. Note that you must also set
# the default access control for these directories, as in the example below.
UserDir public_html
# Control access to UserDir directories. The following is an example
# for a site where these directories are restricted to read-only.
<Directory /home/*/public_html>
AllowOverride FileInfo AuthConfig Limit Indexes
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
<Limit GET POST OPTIONS>
Order allow,deny
Allow from all
</Limit>
<LimitExcept GET POST OPTIONS>
Order deny,allow
Deny from all
</LimitExcept>
</Directory>
# Suexec isn't really required to run cgi-scripts, but it's a really good
# idea if you have multiple users serving websites...
<IfDefine SUEXEC>
<IfModule suexec_module>
<Directory /home/*/public_html/cgi-bin>
Options ExecCGI
SetHandler cgi-script
</Directory>
</IfModule>
</IfDefine>
</IfModule>
</IfDefine>
Look for this option in your configuration.
Options +Multiviews
It will look for
/foo/test
/foo/
/foo
and redirect them to
/foo.[any file]
based upon if it exists and if it fits the content-type requested.
Change the option to this to disable this.
Options -Multiviews