I noticed on Rackspace, when using an Ubuntu instance (10.04; standard LAMP setup), the ".php" suffix on a URL is optional. ie www.example.com/thispage loads thispage.php
When I setup a very similar server on Amazon (default AWS 32-bit ami; a flavor of CentOS/Red Hat) and locally on osX 10.6, the ".php" suffix is required. www.example.com/thispage returns a 404 error, while /thispage.php loads the file as expected.
The most likely cause, in my mind at least, is that there are different default settings in php.ini or the Apache configuration between these different setups, but I can't figure out what it is. Can anyone explain to me where this difference comes from?
NOTE: I know this can be overcome using mod_rewrite, I'm just curious as to this difference in the default configurations.
Check if the MultViews-Option is set.
If it does, and there is no directory like this(e.g. "thispage") , the server will look for files with the filename "thispage" and any extension and deliver(if any found) the best match.
the answer is this http://www.php.net/manual/en/security.hiding.php#45896 , but you're going to need to access httpd.conf file
Related
I am running into some sort of issue when trying to access my local website:
Forbidden
You don't have permission to access /index.html on this server.
Apache Server at ffghost.local Port 34580
I'm using macOS X Server 5.2 with Apache 2.4.18. OS X Server automatically creates two default websites (one on port 80 and one on port 443). I created a new website. It was my understanding that Apache would redirect from the default site to the created site automatically once created. This didn't happen. So, in an attempt to begin de-conflicting I replaced the files where the default site was located with the new website files and all of the sudden am getting the above 404 message.
I have read a lot of possibilities as to why this may be happening. I've run a syntax checker for Apache in terminal and terminal says syntax is ok. So from there I was going to check into the config files, but there are several, and I just want to know the gist behind them.
There seem to be about 4 file extension types. I don't know what they all mean or if they are active.
.config (I'm assuming this is the active file)
.config.prev (I'm assuming this is a previous version or copy of an active config file and is no longer active)
.config.orig (original file? and is no longer active)
.config.default (???)
Also, OS X Server and Apache seem to have the same files in two different places and I'm a little confused on which one to change. If I change one of them will it be reflected in the other? Do I need to change both of them? Additionally, I don't have DNS set up and am unsure if that was the original issue of not pulling up the new website over the default site.
You are mixing several aspects in your question which makes it complicated to give a helpful answer. For example, you say you get Forbidden when accessing your site, but later you mention a status 404. The former might be due to configuring a user group being allowed to access the site, while the latter just means Not found.
As to your actual question about the config files:
The file just ending in .conf is the one that is being used.
However, the Server app uses a lot of of different config files which might be relevant:
Path /Library/Server/Web/Config/apache2 contains the general config files
httpd.conf - general Apache configuration
httpd_server_app.conf - more general configuration
the other files contain configurations for specific applications or webapps (the latter being defined in plist files in /Library/Server/Web/Config/apache2/webapps)
Path /Library/Server/Web/Config/apache2/sites contains config files specific to your websites. They are named something like 0000_127.0.0.1_34543_your.domain.name.conf where 34543 is the configuration for the https (SSL) port, while 35480 would indicate the http port. There is also a file like 0000_127.0.0.1_34543_.conf (no domain name in the file name) which defines the default site.
In addition to these, there are two more configuration file in /Library/Server/Web/Config/proxy which configure the proxy services.
It is not recommended to manually adjust the config files, except for those in the sites subdirectory, because they may get overwritten by the Server app or when updating the Server app.
Important: If you change the files manually, you must re-start the Apache server in order to make the changes effective. Use sudo serveradmin stop/start web to do so.
However, I do not know of a detailed documentation of of all these files, so I try to stay on the safe side and possibly not edit the general config files (only those in sites). I also recommend to write down any manual changes, so they can be reapplied if necessary.
Without exactly knowing what you configured in the Server app and which files you changed how, I'm afraid it is impossible to say what might have gone wrong. I recommend to start all over by removing and re-adding the web sites.
I want to know if my Apache server uses .htaccess files or not. If it uses them, then why and how?
How can I know if my Apache server is using .htaccess or not?
Thank you.
As for why, it's a convenient way for shared-hosting providers to give some access to users who would like to set some configuration options. You obviously wouldn't want everyone to have access to the main configuration file for security purposes. It's also useful for development purposes since you can set different options for different directories.
As for how Apache uses the file, I recommend reading the documentation.
As for how to know if Apache is using .htaccess files, it most likely is. I've yet to meet a shared hosting provider that doesn't. And if you are running your own server, I assume you would know how you set it up. Worst case scenario, you could follow this advice from the docs:
A good test for this is to put garbage in your .htaccess file and reload the page. If a server error is not generated, then you almost certainly have AllowOverride None in effect.
I am having a bit of a problem finding some mod_rewrite details. I am taking over from another PHP web developer. I am used to Ubuntu servers and I am migrating a few sites onto a new Ubuntu server. The old server is CentOS. The old developer used mod_rewrite rules and as they're rather specific, I'm trying to track them down on the server but cannot find them for the life of me. I know it's a bit of a needle in a haystack question but does anyone know where they could be? I've looked within the individual sites var/www/vhost/SITENAME/ config. Not in there. I've looked in the etc/httpd config files too and they're not there. They are also not stored on the file server within htaccess. Thanks for any guidance
Usually the VirtualHost config files are under /etc/httpd/conf.d/.
What you could do is grep -ri rewriterule /etc/httpd/conf*|more to see if the RewriteRules are defined anywhere within the configuration directories.
You should also check grep -i include /etc/httpd/conf/httpd.conf to see if configurations are included from somewhere besides the default Include conf.d/*.conf.
A client has a website running on a dedicated host (either developed, nor managed by myself) in which Apache is generating a very strange behavior.
When the requested url is of the type:
http://obituarieshelp.org/aboutus.html/whatever_here
it actually loads 'aboutus.html' if it exists, even though 'whatever_here' does not exist, and 'aboutus.html' is not a directory.
I took a look at the htaccess file, and everything seems to be fine. I am sure it is apache misconfigured somehow, but for the love of me, I cannot seem to find anything that could point to the problem in httpd.conf
Has anyone experienced the same, or has any suggestions as to why this would be?
This is controlled by the AcceptPathInfo HTTPd directive. The remainder of the path after the file is made available in the PATH_INFO environment/server variable, and scripts can use it to discern additional information about the request.
I have a really irritating problem with PHP on Windows Server 2008 R2. IIS and Apache are running on the same machine (Apache is embedded with another product and it being there is not my choice).
IIS is configured to be able to use multiple versions of PHP, and none of the PHP versions on there were installed with the Windows installer (so php.exe does not exist in the path).
Apache uses one particular version of PHP (5.2.5 Thread-safe - again I can't change this as a 3rd-party application has PHP extensions compiled against this version).
If I check phpinfo() in my Apache site it doesn't have an entry for MySQL, even though php_mysql.dll is enabled in php.ini and it exists in the \ext directory. If I (temporarily) add this version of PHP (same directory, same php.ini) to IIS and set up a test site with phpinfo() it correctly lists MySQL. I know this is not just some strange issue with phpinfo because I have a MySQL-based PHP site running in Apache and it fails with Call to undefined function mysql_connect()
It was suggested that I copy libmysql.dll from the PHP directory to C:\Windows\System32 but this made no difference. As there are multiple versions of PHP on the server I suppose it's possible that the wrong version of libmysql.dll is being loaded, but the PATH doesn't include any directories containing libmysql.dll.
IIS and Apache are looking at exactly the same PHP installation, php.ini, and ext directory, but only IIS can load the MySQL extension. Apache is on the default System account as it looks like System has access to all the DLLs.
The Apache logs say nothing about any DLLs failing to load. I'm logging PHP errors in the event log but nothing is reported about those extensions.
After Googling around the issue I found other suddenly-occurring issues in PHP on Windows server but the usual resolutions - rebuilding php.ini, restarting IIS, restarting the server - haven't helped.
Any suggestions on where to look next are much appreciated!
I know this might not ultimately answer your question but, did you try configuring Apache to execute PHP through FastCGI (mod_fcgid) and use the same binary as IIS does ?
I know you are using mod_php, but calling it via FastCGI will abstract PHP from the webserver process. If extensions are loading fine under PHP called via FastCGI, there is no reason it won't work on a different web server.
Also, I personally beleive that it is a better idea this way since PHP is only called when a *.php file is requested. This way, Apache will not load PHP in memory for every request, which will give you better performance for serving static files, for example.
Update
To do this, you need to download mod_fcgid from http://httpd.apache.org/mod_fcgid/, load the module in your Apache configuration this way,
LoadModule fcgid_module modules/mod_fcgid.so
And then, just specify what binary you want to call when PHP pages are requested:
AddHandler fcgid-script .php
FcgidWrapper "c:/php/php-cgi.exe" .php
Then, files with a .php extension will now be executed by the PHP FastCGI wrapper. Just be sure to specify the same php-cgi.exe binary as IIS is using.
All extensions that were previously available in IIS should now be available in Apache since the PHP installation behind is the same in both environment.
Keep me updated.
1.- check php.ini path in phpinfo.
2.- add php folder to the windows path
http://www.computerhope.com/issues/ch000549.htm
3.- add directive PHPINIDir to apache conf
http://php.net/manual/en/install.windows.apache2.php
4.- uncomment mysql extension in respective php.ini
5.- reload apache
6.- check mysql extension in phpinfo
and please don't copy any files to system32
You will generally need different library dlls for the different versions of PHP you are running. It's best to keep these in their own directories.
There's a few different things that could cause a module not to load, including the PHP version whether you're running a thread-safe or not-thread-safe version and also if the binaries were compiled as VC6 or VC9 †. Usually the easiest way to debug if you're getting any module loading errors is running php.exe from the command line as it will spit out any startup errors (also ensure these are enabled in your php.ini and you're loading the correct php.ini file when you do so).
† IIRC VC6/VC9 is to do with which version of Visual Studio PHP was compiled with.
Ultimately this issue came down to a missing PATH reference. Although IIS doesn't seem to require PHP or PHP modules to exist in the path it seems that Apache (or perhaps my version of PHP?) does. I am lucky in that I only need to run one version of PHP outside IIS, as I have no idea what would happen if I had multiple Apache instances referencing different versions of PHP and multiple PHP directories in the path - presumably one would always fail.
So far it looks like adding Apache's version of PHP to the path hasn't affected the IIS versions of PHP, but I will swear loudly if it suddenly does.