I recntly upgraded from PHP 5.1 to 5.2 on my Windows Server 2003 using IIS6. I selected CGI as before. My PHP folder is as always C:\Program Files\PHP. I also edited my brand new php.ini, enabling all my old extensions and recommended settings for IIS. I like not to keep my old config into a new version.
After upgrade, I just got blank pages in my browser, and the response status was 404 Not found.
I checked my installation twice, using this FAQ, but got no way.
Then I went to IIS Manager, Web Service Extensions. The php Service Extension was Allowed as it should. I deleted the Service Extension and added it. The old extension used short file names containing tilde (PROGRA~) character, but I don'æt know if that gas anything to do with the problem. Anyway, after allowing my" new" Service Extension, pointing to php-cgi.exe as before, mye web sites suddenly worked. So will revommend anyone with thos problem to delete and add the Servcie Extension. It didn't help re-allowing it, restarting IIS or the complete server.
Installation
Cette section traite de questions courantes sur la façon d'installer PHP. PHP est disponible sur la plupart des systèmes d'exploitation (sauf les versions de MacOS antérieures à Mac OSX) et pour quasiment n'importe quel serveur web.
Pour installer PHP, suivez les instructions présentes dans Installation et configuration.
- Pourquoi ne doit-on pas utiliser Apache 2 dans un environnement threadé multiprocesseur de production ?
- Unix/Windows : où doit être placé mon fichier php.ini ?
- Unix : j'ai installé PHP, mais à chaque fois que je charge un document, j'obtiens l'erreur 'Document Contains No Data' ! Que se passe-t-il ?
- Unix : J'ai installé PHP en utilisant des fichiers sources RPM, mais apache ne traite pas les pages PHP. Que se passe-t-il ?
- Unix : J'ai patché Apache avec l'extension FrontPage et subitement, PHP ne fonctionne plus. Est-ce que PHP est incompatible avec l'extension FrontPage pour Apache ?
- Unix/Windows : J'ai installé PHP, mais lorsque je tente d'accéder à un fichier contenant un script PHP via mon navigateur, j'obtiens un écran vide.
- Unix/Windows : J'ai installé PHP, mais lorsque je tente d'accéder à un fichier contenant un script PHP via mon navigateur, j'obtiens une erreur de type 'server 500 error'.
- Quelques systèmes d'exploitations : J'ai installé PHP sans erreur, mais lorsque je tente de démarrer Apache, j'obtiens une erreur du type 'Undefined symbols' : [mybox:user /src/php5] root# apachectl configtest apachectl: /usr/local/apache/bin/httpd Undefined symbols: _compress _uncompress
- Windows : J'ai installé PHP, mais lorsque je tente d'accèder à un fichier contenant un script PHP via mon navigateur, j'obtiens l'erreur : cgi error: The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are:
- Windows : J'ai suivi toutes les instructions, mais je n'arrive toujours pas à faire fonctionner PHP et IIS ensemble !
- Lorsque vous exécutez PHP comme CGI avec IIS, PWS, OmniHTTPD ou Xitami, j'obtiens l'erreur suivante : Security Alert! PHP CGI cannot be accessed directly..
- Comment puis-je savoir si mon php.ini a bien été trouvé et lu ? Cela semble être le cas mais aucun de mes changements n'ont eu d'effet.
- Où dois-je ajouter mon répertoire PHP à la variable PATH sous Windows ?
- Comment rendre le fichier php.ini disponible à PHP sous Windows ?
- Est-il possible d'utiliser la négociation sur le contenu fournie par Apache (option MultiViews) avec PHP ?
- Est-ce que PHP est limité au traitement des méthodes GET et POST ?
- Pourquoi ne doit-on pas utiliser Apache 2 dans un environnement threadé multiprocesseur de production ?
-
PHP est un mortier. C'est un mortier utilisé pour construire de belles applications web en utilisant beaucoup de bibliothèques ensemble, apparaissant comme une seule entité à travers un langage intuitif et facile à apprendre. La flexibilité et la puissance de PHP se fondent sur la stabilité et la robustesse de la plate-forme fondamentale. Il a besoin d'un OS qui fonctionne, d'un serveur web qui fonctionne et de bibliothèques externes pour coller le tout. Lorsqu'un seul de ces éléments arrêtent subitement de fonctionner, PHP doit identifier le problème et le réparer au plus vite. En rendant le cadre fondamental plus complexe en ne séparant pas les exécutions des threads, ni les segments mémoires, ni un endroit clos pour traiter chaque requête entrante, de nouvelles faiblesses sont introduites dans le système PHP.
Si vous voulez utiliser un MPM threadé, regardez du côté d'une configuration FastCGI dans lequel PHP s'exécute dans son propre espace mémoire.
- Unix/Windows : où doit être placé mon fichier php.ini ?
-
Par défaut sous Unix, il doit être placé dans /usr/local/lib qui est en fait <install-path>/lib. La plupart des personnes voudront changer ceci lors de la compilation avec l'option --with-config-file-path. Vous pouvez par exemple le régler de cette façon :
Et alors vous copierez le fichier php.ini-development livré avec les sources vers /etc/php.ini et l'éditer pour l'adapter à vos besoins.--with-config-file-path=/etc
--with-config-file-scan-dir=PATH
Sous Windows, le chemin par défaut de php.ini est le répertoire de Windows. Si vous utilisez le serveur web Apache, php.ini est tout d'abord cherché dans le répertoire d'installation de Apache, c'est-à -dire c:\program files\apache group\apache. De cette façon, vous pouvez avoir un php.ini différent pour chaque version de Apache installée.
Consultez aussi le chapitre sur le fichier de configuration.
- Unix : j'ai installé PHP, mais à chaque fois que je charge un document, j'obtiens l'erreur 'Document Contains No Data' ! Que se passe-t-il ?
-
Cela signifie probablement que PHP rencontre un problème et génère un fichier core. Consultez vos fichiers de logs de votre serveur pour voir si c'est le cas, et tentez de reproduire le problème avec un test simple. Si vous savez utiliser 'gdb', il serait très utile de fournir un backtrace avec votre rapport de bogue, afin d'aider les développeurs à cerner le problème. Si vous utilisez PHP en module Apache, essayez ceci :
-
Stoppez vos processus httpd
-
gdb httpd
-
Stoppez vos processus httpd
-
> run -X -f /path/to/httpd.conf
-
Pointez alors avec votre navigateur vers l'URL posant problème.
-
> run -X -f /path/to/httpd.conf
-
Si vous obtenez un fichier core, gdb doit alors vous en informer.
-
tapez : bt
-
Vous devriez inclure votre backtrace dans votre rapport de bogue. Celui-ci doit être posté sur » http://bugs.php.net/.
Si votre script utilise les expressions rationnelles ( preg_match() et consorts), assurez-vous que PHP et Apache ont été compilés avec les même outils d'expression rationnelles. Cela doit être automatiquement le cas avec PHP et Apache 1.3.x.
-
- Unix : J'ai installé PHP en utilisant des fichiers sources RPM, mais apache ne traite pas les pages PHP. Que se passe-t-il ?
-
En supposant que vous avez installé à la fois Apache et PHP à partir de fichiers RPM, vous devrez commenter ou ajouter au moins quelques unes des lignes suivantes dans votre fichier httpd.conf :
Et ajouter :# Extra Modules AddModule mod_php.c AddModule mod_perl.c # Extra Modules LoadModule php_module modules/mod_php.so LoadModule php5_module modules/libphp5.so LoadModule perl_module modules/libperl.so
... aux propriétés globales ou aux propriétés du VirtualDomain ou vous voulez que PHP officie.AddType application/x-httpd-php .php
- Unix : J'ai patché Apache avec l'extension FrontPage et subitement, PHP ne fonctionne plus. Est-ce que PHP est incompatible avec l'extension FrontPage pour Apache ?
-
Non, PHP fonctionne très bien avec l'extension FrontPage. Le souci vient du fait que le patch pour l'installation de FrontPage modifie la structure d'Apache, qui est relié à PHP. Recompiler PHP (en utilisant 'make clean ; make') après avoir patché Apache avec l'extension FrontPage devrait résoudre ce problème.
- Unix/Windows : J'ai installé PHP, mais lorsque je tente d'accéder à un fichier contenant un script PHP via mon navigateur, j'obtiens un écran vide.
-
Affichez le code source du document dans votre navigateur et vous devriez probablement trouver le code source de votre script PHP. Cela signifie que le serveur web n'a pas envoyé le script à PHP pour interprétation. Quelque chose est donc incorrecte dans le fichier de configuration de votre serveur web - re-vérifier la configuration du serveur web en vous référant aux instructions d'installations de PHP.
- Unix/Windows : J'ai installé PHP, mais lorsque je tente d'accéder à un fichier contenant un script PHP via mon navigateur, j'obtiens une erreur de type 'server 500 error'.
-
Quelque chose se passe mal lorsque le serveur tente d'utiliser PHP. Pour tenter de récupérer un message d'erreur, depuis la ligne de commande, placez-vous dans le répertoire contenant l'exécutable PHP (php.exe sous Windows) et exécutez la commande php -i. Si PHP a un problème quelconque l'empêchant de fonctionner, un message d'erreur devrait s'afficher qui devrait expliquer comment résoudre ce souci. Si un écran de code HTML apparaît (la sortie de la fonction phpinfo()), cela signifie que PHP fonctionne correctement et que le problème doit certainement venir de la configuration de votre serveur web que vous devriez re-vérifier.
-
Quelques systèmes d'exploitations : J'ai installé PHP sans erreur, mais lorsque
je tente de démarrer Apache, j'obtiens une erreur du type
'Undefined symbols' :
[mybox:user /src/php5] root# apachectl configtest apachectl: /usr/local/apache/bin/httpd Undefined symbols: _compress _uncompress
-
Cela n'a actuellement rien à voir avec PHP mais avec la bibliothèque cliente MySQL. Suivant les versions, elle a besoin que PHP soit compilé avec l'option --with-zlib , d'autre non. Ce problème est également traité dans la FAQ de MySQL.
-
Windows : J'ai installé PHP, mais lorsque je tente d'accèder à un fichier contenant un script PHP
via mon navigateur, j'obtiens l'erreur :
cgi error: The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are:
-
Ce message d'erreur signifie que PHP a échoué lors de l'affichage. Pour tenter de récupérer un message d'erreur, depuis la ligne de commande, placez-vous dans le répertoire contenant l'exécutable PHP (php.exe sous Windows) et exécutez la commande php -i. Si PHP a un quelconque souci de fonctionnement, alors un message d'erreur le décrivant s'affichera. Si vous obtenez un écran de code HTML (le contenu du résultat de la fonction phpinfo()), alors PHP fonctionne correctement.
Si PHP fonctionne depuis la ligne de commande, tentez d'accéder à votre script encore une fois via votre navigateur. S'il échoue toujours, alors, il se peut que ce soit l'un des soucis suivants :
- Les permissions de votre script PHP des fichiers php.exe, php5ts.dll, php.ini ou de toute extension nécessaire à PHP que vous tentez de charger, sont telles que l'utilisateur internet anonyme de votre système ISUR_<machinename> ne peut pas y accéder.
- Le script PHP n'existe pas (ou n'est pas à l'endroit que vous pensez, relativement au répertoire racine de votre serveur web). Notez que pour le serveur web IIS, vous pouvez vérifier cela en cochant la case 'vérifier si le fichier existe' lors de la configuration de l'exécution des scripts dans le gestionnaire de services Internet. Si un fichier de script n'existe pas, le serveur web retournera une erreur 404. IIS a également l'avantage d'effectuer toutes les identifications requises à votre place, basés sur les permissions NTLanMan, sur votre fichier de script.
- Windows : J'ai suivi toutes les instructions, mais je n'arrive toujours pas à faire fonctionner PHP et IIS ensemble !
-
Assurez-vous que chaque utilisateur qui a besoin d'exécuter un script PHP possède les droits requis pour exécuter le fichier php.exe ! IIS utilise un utilisateur anonyme qui est ajouté lors de l'installation de IIS. Cet utilisateur doit avoir les droits suffisant sur le fichier php.exe. De même, tous les utilisateurs enregistrés doivent posséder les droits requis pour exécuter le fichier php.exe. Pour IIS4, vous devez lui dire que PHP est un moteur de script. De plus, vous devriez lire cette FAQ.
- Lorsque vous exécutez PHP comme CGI avec IIS, PWS, OmniHTTPD ou Xitami, j'obtiens l'erreur suivante : Security Alert! PHP CGI cannot be accessed directly..
-
Vous devez définir la directive cgi.force_redirect à 0. Par défaut, elle vaut 1, donc, soyez sûrs que cette directive n'est pas commentée (précédée d'un point virgule). Comme toutes les directives, elles sont définies dans le php.ini.
Comme la valeur par défaut vaut 1, il est impératif que vous soyez sûrs à 100% que le bon fichier php.ini a été lu. Lisez cette FAQ pour plus de détails.
- Comment puis-je savoir si mon php.ini a bien été trouvé et lu ? Cela semble être le cas mais aucun de mes changements n'ont eu d'effet.
-
Pour être sûr que votre php.ini a été lu par PHP, effectuez un appel à la fonction phpinfo(). Vers le haut du document résultant, il devrait figurer une liste appelée Configuration File (php.ini). Cela vous indiquera où PHP a cherché le php.ini et si oui ou non il l'a lu. S'il n'apparaît qu'un chemin vers un répertoire existant, cela signifie que vous devez copier votre php.ini dans ce répertoire. Si le php.ini est présent dans le chemin, cela signifie qu'il a bien été lu.
Si le php.ini a bien été lu et que vous exécutez PHP comme module, alors assurez-vous de redémarrer le serveur web après avoir effectué les modifications à votre php.ini.
Voir aussi la fonction php_ini_loaded_file().
- Où dois-je ajouter mon répertoire PHP à la variable PATH sous Windows ?
-
Sous Windows NT+, et Windows Server 2000+:
Allez dans le centre de contrôle et ouvrez l'icône système (Démarrer -> Paramètres -> Panneau de configuration -> Système ou juste Démarrer -> centre de contrôle -> Système pour Windows XP/2003+)
Allez à l'onglet "Avancé"
Cliquez sur le bouton "Variables d'environnements"
Regardez dans le panneau "Variables systèmes"
Trouvez l'entrée Path (vous devriez avoir à faire descendre l'ascenseur pour le trouver)
Double cliquez sur l'entrée Path
Entrez votre répertoire PHP à la fin, sans oublier le point virgule (;) avant (par exemple ;C:\php)
Confirmez en cliquant sur OK
Sous Windows 98/Me, vous devez éditer le fichier autoexec.bat :
Ouvrez Notepad (Démarrer -> Exécuter et entrez notepad)
Ouvrez le fichier C:\autoexec.bat
Repérez la ligne contenant PATH=C:\WINDOWS;C:\WINDOWS\COMMAND;..... et ajoutez : ;C:\php à la fin de la ligne.
Sauvegardez le fichier et redémarrer l'ordinateur
Note: Assurez-vous de redémarrer l'ordinateur après avoir suivi cette procédure afin que les modifications sur la variable PATH soient bien prises en compte.
Le manuel PHP vous encourage à copier les fichiers dans le dossier système de Windows car ce dossier (C:\Windows, C:\WINNT, etc.) se trouve par défaut dans le PATH système. Copier les fichiers dans le dossier système de Windows est depuis obsolète et peut causer des problèmes.
- Comment rendre le fichier php.ini disponible à PHP sous Windows ?
-
Il y a plusieurs façons de faire cela. Si vous utilisez Apache, lisez leurs instructions spécifiques d'installation (Apache 1, Apache 2) sinon, vous devez définir la variable d'environnement PHPRC :
Sous Windows NT, 2000, XP et 2003:
Allez dans le centre de contrôle et ouvrez l'icône système (Démarrer -> Paramètres -> Panneau de configuration -> Système ou juste Démarrer -> centre de contrôle -> Système pour Windows XP/2003)
Allez à l'onglet "Avancé"
Cliquez sur le bouton "Variables d'environnements"
Regardez dans le panneau "Variables systèmes"
Cliquez sur "Nouveau" et entrez "PHPRC" comme nom de variable et le dossier où se trouve votre fichier php.ini comme valeur (par exemple C:\php)
Confirmez en cliquant sur OK et redémarrer votre ordinateur
Sous Windows 98/Me, vous devez éditer le fichier autoexec.bat :
Ouvrez Notepad (Démarrer ->Exécuter et entrez notepad)
Ouvrez le fichier C:\autoexec.bat
Ajouter une nouvelle ligne à la fin du fichier : set PHPRC C:\php (remplacez C:\php avec le dossier où se trouve le fichier php.ini). Notez que le chemin ne peut contenir d'espace. Aussi, si vous avez installé PHP dans le dossier C:\Program Files\PHP, vous devez entrer le chemin C:\PROGRA~1\PHP.
Sauvegardez le fichier et redémarrer l'ordinateur
- Est-il possible d'utiliser la négociation sur le contenu fournie par Apache (option MultiViews) avec PHP ?
-
Si les liens vers les fichiers PHP incluent l'extension, tout fonctionne parfaitement. Cette entrée de la FAQ traite uniquement du cas où les liens vers les fichiers PHP n'incluent pas l'extension et que vous voulez utiliser la négociation sur le contenu fourni par Apache pour choisir les fichiers PHP depuis une URL qui ne contient pas d'extension. Dans ce cas, remplacez la ligne AddType application/x-httpd-php .php par :
Cette solution ne fonctionne pas pour Apache 1 car le module PHP ne captura pas le php-script.AddHandler php5-script php AddType text/html php
- Est-ce que PHP est limité au traitement des méthodes GET et POST ?
-
Non, il est possible de gérer tout type de méthode, comme CONNECT. Les bons en-têtes de réponse peuvent être envoyés avec la fonction header(). Si seules les méthodes POST et GET doivent être gérées, vous pouvez configurer Apache comme ce qui suit :
<LimitExcept GET POST> Deny from all </LimitExcept>
Installing PHP 4 or 5 on Windows Server 2003 x64 results in http error 505. This is not a PHP bug. It is due to running a 32-bit ISAPI DLL under the 64-bit version of IIS 6, as documented here: http://support.microsoft.com/?id=895976
Solution: Flip the Metabase flag for Enable32bitAppOnWin64 as described in http://support.microsoft.com/?id=894435 ,
like this: CSCRIPT ADSUTIL.VBS SET W3SVC/AppPools/Enable32bitAppOnWin64 1
(Alternatively with full path: cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 1)
Finally got IIS 5 and PHP 5 to talk.
What worked for me was:
1) Set
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
W3SVC\Parameters\Script Map]
".php"="your path to php\\php.exe"
2) ensure there is not a php.ini in the windows system folder and that there is one wherever you've put PHP
3) edit php.ini and set cgi force redirect to 0 and cgi.rfc2616_headers = 1
4) Put the PHP scripts in their own folder underneath the inetpub root
5) Open the IIS console, right click your new php folder
In the Directory tab
set application name to the name of the folder
set executable and script as permission
set application protection to low
Click configuration and check that .php is mapped to wherever you put
PHP
Restart IIS
Try a very simple PHP page and it should work
Nigel
Here are my struggle to get PHP 5.2.12 working on Windows XP SP3, IIS 5.1 (Please note Win XP SP3 has issue of FastCGI)
1. Dowloaded installer and installed in C:\Program Files\PHP as ISAPI module
---->Did not work
Added php5isapi.dll in ISAPI Filter and added the extension .php in Home Dir->Configuration
(For every setting change restarted IIS on cmd->iisreset)
---->Did not work
(And the Google was pointing to the Fast CGI issue; Don't know why microsoft has MS-FAST ! )
Uninstalled the PHP and cleaned up the folders, PATH environment variable & PHPRC, the IIS settings and registry entries and shut down(restart is different from shut down) the system to make it very clean
2. Reinstalled the PHP in C:\PHP as ISAPI and did the same as above in IIS
(For every setting change restarted IIS on cmd->iisreset)
---->Did not work
Uninstalled and cleaned up same as above and took a breath to make sure what I am doing wrong.
Shutdown the system.
3. Unzipped the php-5.2.12-Win32.zip and did the same as above (this time manually PATH variable and security permission for the PHP folder and following settings)
short_open_tag = On
error_reporting = E_ALL & ~E_NOTICE
display_errors = On
doc_root = "C:\Inetpub\wwwroot"
extension_dir = "C:\PHP\ext"
cgi.force_redirect = 0
---->Did not work
Uninstalled and cleaned up same as above
Shutdown the system.
4. Downloaded Microsoft Web Platform Installer 2.0 and select the PHP+Fast CGI+Windows Cache for PHP extension and Web Deployment Tools
restarted the system to take effect the settings
---->Did not work
Uninstalled and cleaned up same as above
Shutdown the system
5. Took the prev version of PHP php-5.2.4-Win32.zip unzip the folder and did the following changes:
short_open_tag = On
error_reporting = E_ALL & ~E_NOTICE
display_errors = On
doc_root = "C:\Inetpub\wwwroot"
extension_dir = "C:\PHP\ext"
cgi.force_redirect = 0
set the security permission as IIS_machinename with full access to the C:\PHP folder
------->IT GOT WOKRING
Hope people would be aware of php-5.2.12 and would love the php-5.2.4
I have some additional troubleshooting tips for 53.7, which deals with getting a blank screen on your browser when running a PHP script.
In addition to server misconfiguration, it may also be that PHP isn't configured to output errors to the browser, which is the case if you or your host uses a more secure php.ini. If this is the case, you need to find out where errors are being logged to find out if any errors are preventing normal output from being delivered to the client.
If you have access to php.ini, check the 'display_errors' directive, which is, by default, located under the 'error_reporting' directive. It's helpful to have 'display_errors' on during debugging phases, but best to have it off in production environments.
Related functions: http://php.net/ini_set | http://php.net/error_reporting | http://php.net/error_log
WINDOWS 2003 and IIS. BIG LESSON FOR ME was "don't mess with the optional components".
I had lots of trouble until I tried installing without asking for extras and then it was very smooth.
I have found no need to set up paths.
I have found no need to configure IIS.
I have found no need to change security on the PHP folder.
What works for me with Windows/IIS:
1. You need to be logged-on as "administrator"
2. Run "php-5.2.6-win32-installer.msi"
Your ONLY action during this wizard is to select "IIS ISAPI" as the webserver. Do NOT CHANGE anything else! I am guessing that the optional extras apply only to Apache because after enabling them I see Apache-related error messages.
3. Setup a test virtual directory as you would for an ASP or ASP.NET web app. eg "phptest"
Then use notepad to create a test page eg "test.php"
<?php
phpinfo();
?>
4. In Internet Explorer, test with eg this address
http://localhost/phptest/test.php
IF this does not give you a beautiful page of details THEN start reading other advice on this page - especially helpful for me was the faq advice to test run "php.exe -i" from the command prompt.
One final note to the message below if you are getting the message about not having rights to execute...You need to use IIS right click on the website and choose 'Properties/Home Directory' then on the 'Execute Permissions' combo box you need to choose 'Scripts only'...Click ok...another dialog may appear asking which directories to apply the action too...choose any directories that you intend on using php in and click ok...It should work now...
To get php 5.2.5 to work in IIS on Windows Server 2003
1. Install PHP choose the IIS ISAPI webserver option on the first panel of the php install
2. Make sure your website is accessible for example make sure it works with html files
3. Now startup IIS and click on the Web Sevice Extensions folder icon, you should see the PHP Hypertext Processor installled and enabled. Click on the 'All Unknown ISAPI Extensions' and then click the 'Allow' button.
4. Now you need to give the internet users access to the php executable directory ie c:\php or c:\program files\php by using internet explorer and right clicking the php directory and choosing Properties/Security/Add...Now in the 'Select Users or Groups' dialog that appears in the 'Enter the Object Names to select' type in the name of the internet guest account (ie IUSER_TEMPLATE in my case)...click the check names to make sure you got it right and click the OK button. Finally in the PHP properties dialog click the Internet Guest Account icon and set the permissions to be 'Read & Execute, List Folder Contents and Read'. Click ok and now it should work. Create a very simple php file and test it...
If you get the 404 file not found error then the ISAPI extensions are not allowed (#3 above)
If you get a blank page then the ISAPI extensions are probably setup right but you need to give the internet user access rights to the php executable directory (#4 above)
To limit HTTP Request Methods on the Apache server running PHP you should use mod_rewrite or mod_security instead of LimitExcept, to give you more control over the handling of such http errors. Can go in .htaccess file or httpd.conf
# mod_rewrite
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_METHOD} !^(GET|HEAD|POST)$
RewriteRule .* - [F,L]
</IfModule>
# mod_security
<IfModule mod_security.c>
SecFilterSelective REQUEST_METHOD "!^(GET|HEAD|POST)$" "deny,log,status:403"
</IfModule>
You can use the php request method scanner at askapache to see exactly how your server deals with various request methods, and check that your server is configured properly..
http://www.askapache.com/online-tools/request-method-scanner/
Windows 2000 Server and IIS (SP4 and all patches):
After many frustrating hours of trying to figure out the install (again), It took a while, but here are a couple tips:
PHP working with IIS uses c:\winnt\php.ini
It doesn't matter what you set the path to, nor what you set the PHPRC environment variable to. After you get PHP running correctly in the installation folder (using php -i) copy the php.ini file into the c:\winnt folder.
Here's what worked for me:
- Add PHP path to System environment variable
- Add php5activescript.dll from http://snaps.php.net/ to the PHP folder, then Register it: "regsvr32 php5activescript.dll"
Set extension_dir and doc_root directives in PHP.INI:
extension_dir = C:\WWW\PHP\ext
doc_root = C:\WWW\Site
cgi.force_redirect = 0
(the last cgi.force_redirect isn't required, but I like to set it anyway)
Copy the .INI file into WINNT folder
In IIS Manager, right-click "Default Web Site", Click "Home Directory",
Click "Configuration", "Add" the ISAPI application:
Executable: <your php install>\php5isapi.dll
Extension: .php
Limit to: GET,HEAD,POST
Check: "Script Engine"
Uncheck: "Check that file exists"
Finally: Set up an ISAPI filter:
Click the "ISAPI Filters" tab,
Filter Name: PHP
Executable: <your php install>\php5isapi.dll
Notes: You don't have to set any of your folders as "Script source" folders. .PHP files aren't scripts, merely text files that require processing before being shipped off to the browser, which is what the ISAPI filter does.
Finally, working again.
Chase
For Windows XP users
Just add php.ini to windows/system 32 and also save a copy in the setup folder e.g. c:/php/php.ini, c:/php5/php.ini,
You have to follow the suggestions, add to path, uncomment extensions and voila!!
Had a hard day to MSI install 5.2.3 on WinXP with MySQL. I use a drive substitution (subst drive: path - in my case subst d: c:\drive_d) and installed PHP in D:\PHP - which in reality is C:\DRIVE_D\PHP. To make a long story short - only after (1) changing all substituted D:\ back to C:\DRIVE_D and (2) resolving all DOS short names to Win long names PHP started to work. The first one is clear - the substitution works only for the active console user - not for services or IUSR. For the second one I have no explanation, since DOS short names should work systemwide - maybe Win handles them correctly but PHP not ?
BTW <?php phpinfo(); ?> was of tremendeous help
Meiki
When i first installed PHP 5.2 / 5.1 on Windows 2k3 server standard edition, i got error 404's on every page i tried to load, i then noticed that in the file extention configuration list, .php files where going to E:\PHP\\php5isapi.dll or something similar, the problem was the two back slashes, i'm not sure what their purpose is. After i changed it too one, PHP worked well for about 5 minutes then the Application poop started to crash and a whole new bag of problems fell open, but thats just observation if it helps anyone.
After setting the PHPRC environment variable, none of my PHP files would hit the preprocessor. The browser was just serving out PHP source code right there in the "view source."
The manual was telling me to set this var to "c:\php," but nothing was working. It's almost as if IIS/Win2000 wasn't reading my php.ini at all.
After I set that variable to "c:\php\php.ini," all of a sudden I was getting honest to goodness PHP pages working.
You do not have to restart the whole system make effect of changing the PATH env var. For me (sbs2003) worked automatically.
on older systems you can use
set $Path=%path%;c:\php
command to extend immediately the path var.
<LimitExcept GET POST>
Deny from all
</LimitExcept>
Does not work with Apache2+ & PHP5 . Apache Refuses to start
In setting up PHP 5.0.4 + IIS 6 I can concur with vlad at vkelman dot com that setting the environment variable PHPRC is ineffective at telling IIS where to look for php.ini. The only place PHP5 seems to successfully find php.ini is in C:\Windows. Using PHPIniDir with Apache2 works like a charm, however.
Fixing 404 (file not found) errors with PHP 5.0.3 and IIS 6.0
IIS 6.0 is installed with security settings that don't permit dynamic content. This means that even if all the hints in the FAQ are paid attention to (.ini modified correctly, security and permissions correct for IUSR_xxx user, etc), you still get 404 errors for all php files.
To fix this: IIS Manager -> expand local computer -> Web Services Extensions -> Add web service or extension -> .php, browse to c:\php\php-cgi.exe or wherever you had the php executable installed. That plus setting the doc_root in the .ini file solved the problem.
--BF
Great WAMP 1.4.4 (Apache 1.*, MySql 4.*, PHP 4.*) installation article at http://www.circaware.com/articles.php?id=2
This article details how to install these onto a USB stick--which means changing *nothing* on the host PC, such as registry entries, environment variables, files in the Windows path, NT services, ini files, etc.
The USB stick install seems awkward, but I installed WAMP to my harddrive using this article as a guide (essentially replacing E:\ with C:\), and it works fine. No more trying to decide where the *real* php.ini or my.ini file is that needs to be changed.
PHP 4.3.7.7 and IIS 6 (w2k3 standard)
Followed note from nigel dot salt at hotmail dot com
but had to modify "Script Map" to "ScriptMap"
Also, had to follow note from jimo at mail dot azhsv dot com
after all that - it worked.
As stated within the note "jimo at mail dot azhsv dot com
29-Nov-2003 04:33
PHP 4 and IIS 6.0 (Windows Server 2003)," I found the same steps were requiered for installation of PhP 5 beta 3 on my Windows 2003 server (Standard Edition)
PHP 4 and IIS 6.0 (Windows Server 2003)
Had difficulty getting PHP 4.3.3 to work with Win2003 Ent Server for use with SquirrelMail. Problem found and believed solved. Appears to be something New with IIS 6.0 (More security by Micro$oft) Was getting 404 error and php was not being run as a cgi even though it was in extensions and IIS user had rights to execute it. (php from command line operated correctly)
If you are installing on Windows Server 2003 (only have Enterprise Edition – Not sure if this applies to standard edition), and you have done the normal procedures for inclusion of PHP scripts (either ISAPI or CGI) in IIS, you will still get a 404 error when attempting to execute those scripts even though IIS has rights and the extension points to the correct file. To alleviate this problem, perform the following:
1. Open a command prompt window
2. Change to C:\windows\system32
3. Execute the command: cscript iisext.vbs /AddFile c:\php\php.exe 1 php 0 php
4. Execute the command: cscript iisext.vbs /EnFile c:\php\php.exe
5. To check for correct execution of the above,
6. Execute the command: cscript IisExt.vbs /ListFile – the php extension should be listed
If you try just step 4 without step 3 you get an error that the file is not in the list (and won’t be there till you do step 3 above)
After this, IIS seems to like the php extension and work normally.
For additional reference, see the below 3 Micro$oft KB Articles:
HOWTO: Enable and Disable ISAPI Extensions and CGI Applications in IIS 6.0 (MS KB Article 328360)
HOWTO List Web Server Extensions and Extension Files in IIS 6.0 (MS KB Article 328505)
HOWTO Add and Remove Web Service Extension Files in IIS 6.0 (MS KB Article 328419)
Running Win2K AS + IIS5.0 + PHP 4.3.1, I ran into a nasty problem that I mistakenly thought had to do with something in the php.ini configuration. When I would try to submit a form using the HTTP method GET it would work, but I would get a "404 Page Not Found" error using the POST method.
All my permissions were set correctly, the php.ini was configured correctly. It had to do with URLScan being installed on IIS (see below)
Page 404 File Not Found Error When Using POST method in PHP (and Perl, and otherwise)
-------------------------------------------
This is related to the Microsoft URLScan utility. If you have this problem, the IIS administrator has probably run the IIS Lockdown tool as well as configured URLScan to reject this type of HTTP method when sent in a URL. These tools are meant to enhance web server security.
URLScan configuration files can be found in the \WINNT\system32\inetsrv\urlscan folder on the web server. Specifically, the file to modify is urlscan.ini.
The changes to make are as follows:
1. Make sure UseAllowVerbs=1 under [options]
2. Under the [AllowVerbs] section, list your allowed HTTP methods to include:
GET
POST
For more information on the IIS Lockdown tool and URLScan, visit http://technet.microsoft.com
INSTALLATION ON OPENBSD 3.1 VIA PORTS COLLECTION
Would have succeed but no mysql support.
I commented out the FLAVORS+= dbase filepro mysql mysql_bundled postgresql iodbc in the /usr/ports/www/php4/Makefile and in the configure options added
--with-mysql=/usr/local and it worked.
Good Luck
On windows 2000 installation I've had PHP simply hanging when running a PHP script.
To see exactly what is going wrong with PHP in the context of the IUSR_MACHINENAME account create a shortcut on your desktop to point to cmd.exe.
Right click on the shortcut, and select properties.
Then check the 'run as a different user' checkbox of the property pages of the shortcut.
Double click then shortcut, and you will be prompted for a user account to run the cmd.exe shell under.
Enter IUSR_MACHINENAME (replace machine name with the machine name of your system), and enter the password for the account.
If you don't know the password for the IUSR account you might need to go change it in Administrative Tools->Computer Management.
Enter the password, and you will be dropped into a command prompt.
Now run c:\php\php.exe -i and see if you can catch any error messages.
On my system it had a problem accessing c:\winnt\system32\browscap.ini which I was then able to sort out.
Running PHP as the Administrator user didn't give this problem, so being able to impersonate the IIS account was a very useful diagnostic tool.
When installing or updating php 5.x on Windows 2003 with IIS the installer sets the ISAPI application extension path incrorrectly. (The filename portion of the path is truncated with ~ at the end).
This causes IIS to not serve any .php pages on any of the configured websites.
To solve this, open IIS Manager and expand the tree to "websites". Open "websites" properties dialogue and go to the "Home Directory" tab. Click on the "configuration" button.
In the "Application Configuration" window, select .php from the "Application Extensions" and correct it's path by browsing to the "php5isapi.dll" file in your PHP5 directory.
Choose to replace this configuration option on all configured websites that make use of php when asked.
You can also set this option for individual websites only instead of the top-level website.
If after installting/upgrading PHP on Windows 2000/2003/2008 server with IIS, you're only getting blank pages (or if examining the headers, HTTP 500 errors), try the following:
1. Uninstall PHP and remove all traces of it, IIS ISAPI settings, php.ini and the entire PHP directory.
2. Restart the computer.
3. Install PHP again, you can install and use extensions if you wish.
4. Check the ISAPI settings in IIS (or CGI, depending on what you're using).
5. Restart IIS several times (don't ask me why, it makes no sense).
6. If it still doesn't work, copy the following files to %WINDIR%\system32\ from your PHP directory.
(Some files might not exist, I think it depends on your choice of extensions.)
libmysql.dll (if you're using MySQL)
libeay32.dll (even if you're not using OpenSSL)
ssleay32.dll (even if you're not using OpenSSL)
libmcrypt.dll (If you're using mcrypt)
libmhash.dll (If you're using mhash)
7. Restart IIS again.
8. If it still doesn't work, check if you have additional lib*.dll in your PHP folder and try copying these to %WINDIR%\system32\.
The above has helped me 3 times when updating my PHP installation (first from 5.05->5.1.4, second from 5.1.4->5.2.1 and today from 5.2.1->5.2.6).
Each time I've run into the exact same problem, blank pages (500 internal server error).
I hope this helps someone.
In addition of what jimo at mail dot azhsv dot com said:
I don't know which idiot at Microsoft wrote those Knowledge Base articles (http://support.microsoft.com/kb/328360/EN-US/) - maybe the same idiot who created "Web Server Extensions". But the same - adding extensions and enabling them may be achived much simplier: just open III Manager, go to "Web Server Extensions" and add what you need interactively.
I'm trying to make both PHP 4 and PHP 5 running as modules on my machine, PHP 4 under IIS and PHP 5 under Apache 2. It turns out that it much easier to work with Apache. In particular, it allows to use PHPIniDir directive to point PHP to php.ini file. IIS is supposed to allow it with setting the PHPRC environment variable, but for some reason it doesn't work on my machine so far.
I figured out why i get this error with just a virtual directory and not the root:
8. Windows: I have installed PHP, but when I to access a PHP script file via my browser, I get the error: cgi error:
The specified CGI application misbehaved by not
returning a complete set of HTTP headers.
The headers it did return are:
---------------------
Look at the php.ini file and look for
doc_root =
set it to nothing so that it does not only look for that directory. I hope it helps people with IIS and PHP
