The problem is the following:
There is one server that I deploy to and for some reason the server does not respond to urls as usual. What I mean is when I have a file called somefile.php uploaded to mysite.com/ and I type in browser mysite.com/somefile the file somefile.php gets called instead of saying 404 not found. I think that this is weird and for some reason it prevents my .htaccess file to rewrite correctly, because the file somefile.php gets called and if there is information after mysite.com/somefile like mysite.com/somefile/someotherfile, someotherfile gets ignored and somefile.php gets displayed. I have all other .htaccess files deleted even in parent directories of the server and still the same result. I hope that you can hep me.
On localhost this problem is not observed. I get 404 not found as I should...
Sounds like you have MultiViews currently enabled. Try disabling them.
Multiviews
MultiViews is a per-directory option, meaning it can be set
with an Options directive within a , or
section in httpd.conf, or (if AllowOverride is properly set) in
.htaccess files. Note that Options All does not set MultiViews; you
have to ask for it by name.
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.*, and effectively fakes up a type map
which names all those files, assigning them the same media types and
content-encodings it would have if the client had asked for one of
them by name. It then chooses the best match to the client's
requirements.
http://httpd.apache.org/docs/2.2/content-negotiation.html#multiviews
Related
I tried to allow access to a directory by using the .htaccess file.
This is my .htaccess:
<Directory Bilder_Team>
Options Indexes FollowSymLinks
AllowOverride None
</Directory>
The directory is "Bilder_Team". If I open the link to this directory, it shows me
500 Internal Server Error
How can I fix this?
Use this htaccessCheck for future checks or problems. Your problem as you could see, once checked, is that you are not allowed tags such as <Directory> in .htaccess files.
Instead put the .htaccess directly into the Build_Team directory and leave off the surrounding tags.
Possibly, a bigger problem is the use of AllowOverride None, which disables the use of .htaccess files and, obviously, has no part of any .htaccess file. AllowOverride directive can only be part of the main config file!
As shown the snippet is correct iff put in the httpd.conf file (name could vary). Which actually, if possible, is the better way to do it.
For more information about security concerns, you could refer to this StackOverflow answer.
Hope this helps!
I'm working on a PHP project using Apache 2.2.22 and PHP 5.3.10 and I'm running into an issue where index and index.php are being treated as the same file.
I have an admin/index.php that redirects to admin/index to allow my mod_rewrite rules in .htaccess to take over and reroute the request into a custom framework. The problem is, when the browser goes to admin/index it goes into an infinite redirect loop because the request is being sent to admin/index.php which redirects to admin/index
I've tried removing the htaccess file to see if there was a problem with my mod_rewrite rules that was causing it and it didn't change anything. It just redirects to admin/index endlessly.
I've never heard of this behavior before, skimming over some Google results and skimming through the apache configuration files didn't show anything really obvious. Has anyone seen this before and know how to fix it?
EDIT:
Below is the code being used by the index.php to redirect to index.
<?php
header("Location: index");
die();
This may be due to MultiViews being enabled:
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.*, and effectively fakes up a type map
which names all those files, assigning them the same media types and
content-encodings it would have if the client had asked for one of
them by name. It then chooses the best match to the client's
requirements.
— https://httpd.apache.org/docs/2.2/content-negotiation.html#multiviews
Try adding Options -MultiViews to your .htaccess
Enable rewrite Logging inside Apache and raise the log level. That way apache will tell you exactly, step by step, what request is rewritten how, in which order and why.
I made a transfer of a CMS from one server to another. On the new server an image was not found. I looked in the HTML code and saw
<img src="/images/john" alt="john" />
The picture had no extension like *.jpg. But why did it work on the old server? It is the same code, same database and same htaccess file. Even Internet Explorer can find the picture.
Is an Apache or PHP configuration responsible for that behavior? I only want to find out why.
Is it possible that MultiViews is enabled on the old server but not on the new one? MultiViews is an Apache feature that lets you query for files without including the extension (so images/john might return the file at images/john.jpg). It is intended (as far as I'm aware) to allow you to have multiple versions of the same page, with the ultimate version picked depending on the user's locale; a browser requesting index from Spain might get index.es.php while in Japan it might get index.jp.php. I've never used this feature myself, so I don't know if that's the correct usage to serve locale-dependent pages, but I do know that MultiViews has the side effect of serving index.php in response to index.
Note that MultiViews is controlled by the Options directive, and it is the only such option that is not included in All. So to get all options including MultiViews, you would need Options All MultiViews in your .htaccess file. This may or may not enable MultiViews depending on the Allow Override directive in Apache's configuration for your directory; if you're on shared hosting there's nothing you can do but complain (although they tend to allow all .htaccess overrides to avoid such complaints).
Is there anyway to use PHP to check the value of AllowOverride too see if .htaccess will have any effect?
I am not aware of a clean, direct way to do this.
If you have http access to the folder you want to check this for, you could write something into the .htaccess file that will trigger a certain kind of output.
For example, you could set a header (this has an added dependency on mod_headers, though):
<FilesMatch "\.(php)$">
<IfModule mod_headers.c>
Header set htaccess_works "yes"
</IfModule>
</FilesMatch>
then make a request from PHP, and check the response headers, e.g. using curl's CURLOPT_HEADER. If they contain the htaccess_works header, it works.
Another method that is terrible but guaranteed to work independently from specific Apache modules is to programmatically write gibberish into the .htaccess file, then to make a curl request like above, and to check for a 500 status code. If it throws a 500, the .htaccess file got interpreted. But as said, this is terrible - if possible, go with the headers method instead.
In complement to #Pekka response:
AllowOverride can be set to None or All, but as well to a specific list of terms:
AuthConfig, FileInfo, Indexes, Limit, Options. So you could be allowed to use a Header instruction but not Deny, for example.
So a way to test the real value of AllowOverride is to add this to your .htaccess:
#AuthConfig
AuthName "Secret"
#FileInfo
ErrorDocument 404 index.php
#Indexes
DefaultIcon /icon/unknown.xbm
#Limit
Allow From All
#Options
Options FollowSymLinks
Then if you have an 500 error comment lines to detect which words (sections) are forbidden. You'll get an error 500 until you remove every forbidden instruction. When you'll know the allowed sections you'll have to check the documentation for the complete list of allowed instructions.
If you do not have any error you have AllowOverride None or All. Then alter the Deny/Allow to:
Deny From All
If you have the 403 result it's a AllowOverride All.
Easiest way
Add: show-error in the first line on your page an load domain via browser to trigger a 50x error
Another method that is terrible but guaranteed to work independently
from specific Apache modules is to programmatically write gibberish
into the .htaccess file, then to make a curl request like above, and
to check for a 500 status code. If it throws a 500, the .htaccess file
got interpreted. But as said, this is terrible - if possible, go with
the headers method instead.
What is wrong with my apache-conf, why is the file also reachable under a folder-path without an extension? I haven't set any rewrite rules and there are no .htaccess files.
This is the default os x apache installation.
Apache's content negotiation has an option called MultiViews which makes a file available without its extension:
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.*, and effectively fakes up a type map which names all those files, assigning them the same media types and content-encodings it would have if the client had asked for one of them by name. It then chooses the best match to the client's requirements.