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.
Related
I want to change my url from
http://localhost/delhian/destinations_list.php?ref=monuments_in_delhi
to
http://localhost/delhian/destinations_list/monuments_in_delhi
I have written the following htaccess rules.
RewriteEngine on
RewriteRule ^destinations_list/([A-Za-z_]+)/?$ destinations_list.php?ref=$1
I don't know what I'm doing wrong here but this isn't working.
When I'm accessing the URL
http://localhost/delhian/destinations_list/monuments_in_delhi
It is showing me Undefined index ref.
Can anyone tell me what I'm missing here, why it is not working and what is the meaning of this message Undefined index ref?
Add that, at the top of your htaccess, to disable MultiViews:
Options -MultiViews
The Apache docs on mod_negotiation, describes what the Multiviews Option does, when enabled:
If the
server receives a request for /some/dir/foo and /some/dir/foo does not
exist, then the server reads the directory looking for all 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, and returns that
document.
I have xsendfile module working and files are being served using X-Sendfile header. But somehow files from any folder gets served.
How do I rectrict it so that I can use X-sendfile headers only for specific folders?
I have tried setting XSendFilePath, even then files outside that folder also get sent if I use X-Sendfile header.
This is what I have in my virtualhost section
XSendFile on
XSendFilePath /home/domain/public_html/files
If I use php to send files from /home/domain/public_html/abc using X-Sendfile. It gets sent without any problem. I do not want this. I only want X-Sendfile to work for files within /home/domain/public_html/files.
Try with the XSendFilePath directive
XSendFilePath allow you to add additional paths to some kind of white list. All files within these paths are allowed to get served through mod_xsendfile.
It is imporant the the XSendFilePath directive is in a apache config file context that is relevant to the url you are using, e.g. not within a virtual host section which is not interpreted due your actual virtual host (in your url).
probably and in most configurations, XSendFilePath is used in the main section of apache config file, not in a specific context like virtual host, dolmain, etc.
does this help?
XSendFilePath /tmp
<VirtualHost *>
ServerName www.someserver.com
XSendFilePath /home/userxyz
</VirtualHost>
(first occurance of XSendFilePath -> works globally, second occurance does only work if your php script producting the XSendFile header is called from within domain www.someserver.com)
I am working with a colleague to set up their local environment on a MAC in XAMPP, on windows my vhost looks like the one below.
When I access a URL like http://domain.local/cgi-bin/handler.php the web server processes the PHP correctly but on his we get a 500 server error and this message...
The server encountered an internal error and was unable to complete your request.
Error message:
Premature end of script headers:
We tried changing the name of the cgi-bin folder to something else as I noticed there was another alias in httpd.conf but this had no effect...so it seems to me like the issue is permissions related.
We believe the alias is setup ok as accessing http://domain.local/cgi-bin/filenothere.php which doesn't exist throws a 404 as expected, any .html/.pl files fail to execute.
The permissions that exist on the cgi-bin folder are...
rwxrwxrwx dave staff
and is owned by the user and group....
dave staff
Vhost
<VirtualHost *:80>
ServerAdmin webmaster#example.com
ServerName www.domain.local
ServerAlias domain.local
ServerAlias api.domain.local
# Indexes + Directory Root.
DirectoryIndex index.php
DocumentRoot E:/home/www/www.domain.co.uk/htdocs/
# CGI Directory
ScriptAlias /cgi-bin/ E:/home/www/www.domain.co.uk/cgi-bin/
<Location /cgi-bin>
Options +ExecCGI
</Location>
# Logfiles
ErrorLog E:/home/www/www.domain.co.uk/logs/error.log
CustomLog E:/home/www/www.domain.co.uk/logs/access.log combined
</VirtualHost>
Any idea what is causing this PHP file to not be executed?
UPDATE
Tried adding a header to say that the content is PHP to the start of the PHP file and this now simply outputs the PHP code.
It's as if any path specified in as an Alias is accessible but the server doesn't know how to execute the content, this is for HTML as well as PHP
I think you need a section for your cgi-bin.
The fact that your server can show you the script sources means the server has at least read permissions on /file/system/path/to/cgi-bin and IIRC that clashes with ScriptAlias b/c ScriptAlias expects /file/system/path/to/cgi-bin to be unaccessible for security reasons. I think your solution should look something along the lines of:
<Directory /file/system/path/to/cgi-bin>
Options ExecCGI
SetHandler cgi-script
</Directory
There is (very) rarely a need to run PHP scripts as CGIs given that the PHP module for Apache can execute them directly. Try adding this to your Apache config:
<FilesMatch \.php$>
SetHandler application/x-httpd-php
</FilesMatch>
Afterwards simply place the PHP scripts into the document root for the site and see if they work. You'll want to remove the /cgi-bin/ part of the URL.
You say you're setting XAMMP on a Mac, but you have a drive letter (E:) prefixing your paths. OS X does not have drive letters like Windows, and this may also be causing (part of) your issue.
I don't know much about settings used. But I think you should go through following links. Might get some help.
http://www.sean-barton.co.uk/2009/02/setting-up-a-phpmysql-local-development-environment-on-a-mac-doing-it-properly/
http://docs.joomlabamboo.com/using-joomla/setting-up-a-quick-start-package-on-your-local-server-xampp-pc
http://www.adobe.com/devnet/dreamweaver/articles/setup_php.html
How to create Mac OS X dev environment for legacy PHP app?
Assuming that PHP is running in Safe Mode you may need to "open" your cgi-bin directory, as the execution of user (PHP) scripts is limited to the DocumentRoot and it's subfolders.
For all I know you could do that in two ways
1. Edit your php.ini
Locate the line containing open_basedir. If there's a comment at the beginning of the line - a semicolon - remove it. Then add your cgi-bin directory.
open_basedir = "E:\home\www\www.domain.co.uk\cgi-bin\"
If you need to open more than one directories you can use semicolon ; as a separator. On Linux based server, use a colon :
open_basedir = "E:\home\www\www.domain.co.uk\cgi-bin\;E:\home\www\www.domain.co.uk\another_dir\"
In cases like mine, where your server is hosted by third party, you'd need the second option (well sort of)
2. Edit your VirtualHost
Add the following to your VirtualHost, i.e. after DocumentRoot:
php_admin_value open_basedir "E:\home\www\www.domain.co.uk\cgi-bin\"
Same rules apply here for multiple directories and difference between Linux and Windows systems as above.
Hope that helps
Do you know whether PHP is running as a CGI program or as a webserver module? You should be able to find this out if you can get a phpinfo() page working (maybe from a regular folder inside the website root). If you're running as a webserver module then you should have a section near the top with a heading of Server API which says Apache 2.0 Handler (or equivalent).
From these pages:
https://bugs.php.net/bug.php?id=13316
http://php.net/manual/en/install.unix.commandline.php
http://gallery.menalto.com/node/8955
... it seems that it may be either due to PHP running as a CGI script, or else a conflict between PHP and another CGI handler.
One of the posters on the third linked page found that their similar-sounding end of script headers issue was resolved by removing / commenting out the Options +ExecCGI line in their .htconfig / vhosts file.
Might be worth having a read through the above links to see if your problem is related.
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).
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