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
php 설치관련 문의내용 정리
9. 윈도우: PHP를 설치했습니다. 그런데 웹브라우저로 PHP스크립트 파일을 보려하면 다음과 같은 에러가 발생합니다.
10. 윈도우: 모든 지시대로 따랐습니다. 그런데 여전히 PHP가 IIS와 연동이 되지 않습니다.
11. IIS나 PWS나 OmniHTTPD나 Xitami과 함께 PHP를 CGI로 실행시킬때, 다음과 같은 에러가 발생합니다. Security Alert! PHP CGI cannot be accessed directly..
12. 변경한 php.ini파일이 적용되고 있는지 어떻게 알수 있습니까? 설정이 변경된대로 적용이 되고 있는것 같지 않습니다.
그리고 나서 설치 디렉토리 안의 php.ini-dist파일을 /etc/php.ini으로 복사하고 원하는 설정값으로 바꾸면 됩니다.
And add:
아파치의 전역적인 설정으로 놓던가, 아니면 PHP를 지원해줄 버추얼 도메인(VirtualDomain)내에 설정하면 됩니다.
add a note User Contributed Notes
설치
작성자 : 김영철
등록날짜 : 2009.01.14 12:29
4,014
이 섹션은 PHP 설치에 관련되어 자주 문의되는 것들을 다룹니다. PHP는 거의 모든 OS에서 사용가능합니다 (현재까지 OS X 이전의 MacOS는 제외된다) 그리고 거의 모든 웹서버와 연동이 가능합니다.
PHP 설치시에는 설치 디렉토리(PHP소스를 압축풀어놓은곳)밑의 INSTALL파일에 적힌 설치방법을 따릅니다. 윈도우 사용자는 install.txt파일도 살펴봐야 합니다. 이 링크도 윈도우 사용자에게 도움이 됩니다.
- 1. 유닉스/윈도우: php.ini 파일은 어느곳에 있어야 합니까?
- 2. 유닉스: PHP를 설치했습니다. 그런데 PHP파일을 읽으려고 하면, 'Document Contains No Data'라는 메시지가 보입니다. 대체 뭐가 잘못된거죠?
- 3. 유닉스: RPM으로 PHP를 설치했습니다. 그런데 아파치가 PHP 페이지를 제대로 처리하지 못합니다.
- 4. 유닉스: RPM으로 PHP3를 설치했습니다. 그런데 필요한 데이터베이스와의 연동은 어떻게 해야 합니까?
- 5. 유닉스: 아파치를 Frontpage확장이 가능하도록 패치했습니다. 그런데 갑자기 PHP작동이 중단되었습니다. 아파치 FrontPage확장과 PHP는 호환되지 않습니까?
- 6. 유닉스/윈도우: PHP를 설치했습니다. 그런데 웹브라우저로 PHP스크립트 파일을 읽으려고 하면 하얀 화면만 보입니다.
- 7. 유닉스/윈도우: PHP를 설치했습니다. 웹브라우저로 PHP스크립트를 보려고 하면 500 서버 에러가 발생합니다.
- 8. 특정 운영체제: 에러없이 PHP를 설치했습니다. 그런데 아파치를 실행하려하면 undefined symbol error 가 발생합니다.
| <PRE class=programlisting>[mybox:user /src/php4] root# apachectl configtest apachectl: /usr/local/apache/bin/httpd Undefined symbols: _compress _uncompress</PRE> |
| <PRE class=programlisting>cgi error: The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are:</PRE> |
유닉스에서는 기본값이 /usr/local/lib입니다. <install-path>/lib과 같은 디렉토리입니다. --with-config-file-path이라는 옵션으로 그 위치를 변경할수 있습니다. 예를 들면,
| <PRE class=programlisting>--with-config-file-path=/etc</PRE> |
| <PRE class=programlisting>--with-config-file-scan-dir=PATH</PRE> |
윈도우에서는 php.ini위치 기본값은 윈도우(Windows) 디렉토리입니다. 아파치(Apache)가 설치되어 있으면, 최초 php.ini탐색 위치는 아파치 설치디렉토리가 됩니다. 즉 c:\program files\apache group\apache경로에서 제일 먼저 찾게 됩니다. 이런 방식으로 서로다른 아파치 버전별로 php.ini파일을 둘 수 있게 해줍니다.
설치 파일에 관한 챕터도 보세오.
PHP의 에러로 인해 코어 덤프(core-dumping)가 되었을 가능성이 높습니다. 무슨 문제인지 알라보려면 웹서버의 에러 로그(error log)을 확인하세요. 좀더 원인을 밝히기 위해서는 에러가 일어나는 상황을 재연해야 합니다. gdb를 사용할줄 안다면, 버그 레포트(bug report)를 포함하는 실행추적(backtrace)를 개발자에게 보냄으로써 원인을 밝히는데 큰 도움을 줄 수 있습니다. 아파치 모듈로 PHP를 사용한다면 다음처럼 하세요.
-
아파치 프로세스를 멈춘다
-
gdb httpd 명령을 실행한다
-
아파치 프로세스를 멈춘다
-
> run -X -f /path/to/httpd.conf (gdb에서)
-
웹브라우저에서 아까의 에러를 발생시키는 URL을 읽어들임
-
> run -X -f /path/to/httpd.conf (gdb에서)
-
코어덤프(core dump)가 생긴다면, gdb는 이 사실을 보고함
-
type: bt
-
버그 레포드(bug report)안에 실행추적(backtrace)한 과정을 넣어서 http://bugs.php.net/에 보내세요.
PHP스크립트 내에 정규표현식(regular expression)함수 (ereg()관련 함수들)를 사용하면 PHP와 아파치가 같은 정규표현식 패키지여야 합니다. 이것은 PHP와 아파치 1.3.x버전에서는 자동적으로 일치시켜줍니다.
아파치와 PHP 모두 RPM으로 설치했다고 가정하면, httpd.conf파일에서 주석 처리해줄 부분과 추가해줘야 할 부분이 있습니다. 다음 줄을 보고 설치된 버전에 맞게 처리해 주기 바랍니다.
| <PRE class=programlisting># Extra ModulesAddModule mod_php.cAddModule mod_php3.cAddModule mod_perl.c# Extra ModulesLoadModule php_module modules/mod_php.soLoadModule php3_module modules/libphp3.so /* for PHP 3 */LoadModule php4_module modules/libphp4.so /* for PHP 4 */LoadModule perl_module modules/libperl.so</PRE> |
| <PRE class=programlisting>AddType application/x-httpd-php3 .php3 /* for PHP 3 */AddType application/x-httpd-php .php /* for PHP 4 */</PRE> |
PHP3가 빌드되는 방법때문에, 유연한 PHP RPM을 만들기는 쉽지 않습니다. 이와 관련된 이슈가 PHP4에 설명이 되어있습니다. PHP3설치를 위해서는 PHP 설치디렉토리 밑의 INSTALL.REDHAT 파일을 참조하세요. PHP3를 RPM으로 설치하고자 한다면 반드시 읽어야 합니다.
RPM 배포자들은 설치를 단순화시키기 위해 데이터베이스 지원없이 설치되도록 설정해놓습니다. 그리고 또다른 이유는 RPM은 표준적인 /usr/local/이 아니라 /usr/디렉토리를 사용하기 때문입니다. 따라서 지원할 데이터베이스와 데이터베이스 서버의 상위디렉토리를 RPM spec 파일에 설정해야 합니다.
다음은 아파치의 모듈로 설치하여 MySQL 데이터베이스 지원이 되도록 설치하는 과정을 소개합니다.
여기에서 소개하는 것은 PHP를 지원하는 데이터베이스에 맞게 변경해야 합니다. 이 예는 RPM버전으로 MySQL과 아파치를 설치했다고 가정한것입니다.
-
우선 mod_php3를 제거한다:
<PRE class=programlisting>rpm -e mod_php3</PRE> -
그리고 소스 rpm을 구해서 설치한다, --rebuild가 아니다.
<PRE class=programlisting>rpm -Uvh mod_php3-3.0.5-2.src.rpm</PRE> -
/usr/src/redhat/SPECS/mod_php3.spec파일을 편집한다.
%build 섹션에서 원하는 데이터베이스 지원에 관한 정보와 경로를 넣는다.
MySQL일 경우에는
%build 섹션은 다음처럼 되었을것이다.<PRE class=programlisting>--with-mysql=/usr \</PRE> <PRE class=programlisting>./configure --prefix=/usr \ --with-apxs=/usr/sbin/apxs \ --with-config-file-path=/usr/lib \ --enable-debug=no \ --enable-safe-mode \ --with-exec-dir=/usr/bin \ --with-mysql=/usr \ --with-system-regex</PRE> -
여기까지 되었으면 다음처럼 rpm 파일을 만든다:
<PRE class=programlisting>rpm -bb /usr/src/redhat/SPECS/mod_php3.spec</PRE> -
그리고나서 rpm을 설치한다.
<PRE class=programlisting>rpm -ivh /usr/src/redhat/RPMS/i386/mod_php3-3.0.5-2.i386.rpm</PRE>
아닙니다. PHP는 FrontPage 확장과 잘 동작합니다. 문제는 FrontPage패치가 아파치의 구조를 변경시키는데 있습니다. 이 구조가 PHP와 관련되어있는부분입니다. FP 패치 후에 PHP를 다시 컴파일하세요(make clean; make). 그러면 해결됩니다.
웹브라우저에서 '소스 보기'를 해보면 PHP스크립트의 소스를 볼수도 있습니다. 이것은 웹서버가 PHP를 해석한 후에 보내주지 않았다는 것이고, 웹서버 설정이 잘못되었다는 것입니다. PHP와 관련되어 있는 서버 설정을 다시 점검하십시오.
이 에러는 웹서버가 PHP를 실행하려고 할때 무슨 문제가 있다는것입니다. 좀더 구체적인 에러 메시지를 보려면, 커맨드 라인에서 PHP 실행파일 (윈도우는 php.exe)이 있는 디렉토리로 이동하세요. 그리고 php -i명령을 실행하세요. PHP가 어떤 문제가 있다면, 관련된 에러 메시지가 보일것입니다. 이 에러메시지를 통해서 다음에 해야할 일들을 위한 단서를 얻을 수 있습니다. PHP의 html변환된 코드를 볼수 있다면(phpinfo()함수의 실행결과) PHP는 작동하는것입니다다. 웹서버 설정과 관련된 문제라면, 다시 점검하십시오.
8. 특정 운영체제: 에러없이 PHP를 설치했습니다. 그런데 아파치를 실행하려하면 undefined symbol error 가 발생합니다.
<PRE class=programlisting>[mybox:user /src/php4] root# apachectl configtest apachectl: /usr/local/apache/bin/httpd Undefined symbols: _compress _uncompress</PRE>이 에러는 PHP와 관련된것이 아닙니다. MySQL의 클라이언트 라이브러리 (client libraris)와 관련된 문제입니다. --with-zlib옵션이 필요할수도 있습니다. 이것과 관련된 문제는 MySQL FAQ를 참조하세요.
9. 윈도우: PHP를 설치했습니다. 그런데 웹브라우저로 PHP스크립트 파일을 보려하면 다음과 같은 에러가 발생합니다.
<PRE class=programlisting>cgi error: The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are:</PRE>이 에러 메시지는 PHP가 출력에 실패했다는것을 의미합니다. 좀더 구체적인 에러 메시지를 보려면, 커맨드 라인에서 PHP 실행파일 (윈도우는 php.exe)이 있는 디렉토리로 이동하세요. 그리고 php -i명령을 실행하세요. PHP가 어떤 문제가 있다면, 관련된 에러 메시지가 보일것입니다. 이 에러메시지를 통해서 다음에 해야할 일들을 위한 단서를 얻을 수 있습니다. PHP의 html변환된 코드를 볼수 있다면(phpinfo()함수의 실행결과) PHP는 작동하는것입니다.
PHP가 커맨드 라인에서 일단 잘동한다면, 다시 웹브라우저상에서 접근을 시도합니다. 아직도 문제가 발생한다면 원인은 다음중에 있을 가능성이 있습니다.
-
PHP 스크립트 파일, php.exe, php4ts.dll, php.ini 그리고 다른 PHP 확장 파일들은 익명 인터넷 유저(anonymous internet user) 인 ISUR_<machinename> 가 접근할 수 있도록 파일 권한을 설정해야 합니다.
-
이 스크립트 파일이 존재하지 않는것입니다 (또는 웹서버의 루트 디렉토리와 관련되어 있는 그 파일이 거기 없던가). IIS에서는 인터넷 서버 매니저(Internet Server Manager)내의 스크립트 매핑을 설정할 때 'check file exists'박스를 클릭함으로써 이 에러를 잡을수 있습니다. 스크립트가 거기에 없다면 웹서버는 404에러를 발생시킵니다. There is also the additional benefit that IIS will do any authentication required for you based on the NTLanMan permissions on your script file.
PHP를 실행시키려고 하는 유저가 php.exe를 실행할 권한이 있는지 확인하세요! IIS는 익명 유저(anonymouse user)가 필요합니다. 이 유저는 IIS 가 설치될때 추가됩니다. 이 유저가 php.exe 을 실행시킬 권한이 필요합니다. 또한, 다른 검증된 유저도 php.exe를 실행시킬 권한이 필요합니다. IIS4에서는 PHP가 스크립트 엔진이라는것을 알려줄필요가 있습니다. 좀 더 알아보려면, 이 faq 를 참조하세요.
11. IIS나 PWS나 OmniHTTPD나 Xitami과 함께 PHP를 CGI로 실행시킬때, 다음과 같은 에러가 발생합니다. Security Alert! PHP CGI cannot be accessed directly..
cgi.force_redirect를 0으로 놓아야 합니다. 기본값(default)은 1 입니다. 모든 설정치(directive)는 php.ini파일에서 설정됩니다.
기본값(default)는 1이기 때문에 현재의 php.ini파일이 적용되는지 확인하는것이 매우 중요하다. 더 자세한 것은 이 faq를 참고하세요.
php.ini파일이 PHP에 의해 읽히고 있는지 확인하기 위해서는 phpinfo()를 실행시켜서 제일 윗쪽에 Configuration File (php.ini)부분을 확인해야 합니다다. 이 부분을 보면 PHP가 어디에서 php.ini파일을 찾는지 알수 있습니다. 단지 디렉토리 경로(PATH)만 존재한다면 읽히지 않는것입니다. 그 경로로 php.ini파일을 놓아야 합니다. 그 경로 안에 php.ini도 같이 있으면 읽히고 있는것입니다.
php.ini파일이 읽히고 있지 않고 모듈로 PHP가 실행되고 있다면 php.ini파일을 변경한 후에 PHP를 재시동해야 합니다.
add a note User Contributed Notes설치
Meiki67 skipthis at geemail
07-Jun-2007 04:41
07-Jun-2007 04:41
gui dot priaulx at gmail dot com
03-Jun-2007 12:05
03-Jun-2007 12:05
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. Curtis
18-May-2007 07:39
18-May-2007 07:39
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 knutw at sparhell dot no
06-Nov-2006 09:15
06-Nov-2006 09:15
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. signd3 at yahoo dot com
23-Sep-2006 12:37
23-Sep-2006 12:37
re: Installation FAQ 13-Sep-2006 07:03
If you put the full path to your php.ini including the filename in the environmental variable PHPRC, my suspicion is you are in fact not using the php.ini that you think you are. Look at the contents of phpinfo() to verify this, and you will probably see that your php.ini location is C:\\Windows.
The reason for this is that if php does not find a valid php.ini in any path, it will load a default configuration. I too had the problem that when I set the PHPRC variable, the preprocessor was not parsing php content. When I made the change of PHPRC to the full path C:\\php\\php.ini and restarted IIS, it worked, but none of my settings in php.ini were in place.
Eventually I tracked my problem down to the recommended php.ini was causing my problem, and when I used php.ini-dist, everything worked correctly. My PHPRC is now set to
C:\\php, and phpinfo() correctly displays my php.ini path as C:\\PHP\\php.ini.
I can assure you the steps in the FAQ are correct for IIS 5.1, with php 5.1.6 isapi dll.
Hope this helps someone else. 13-Sep-2006 07:03
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. info at kylierose dot com dot au
02-May-2006 03:22
02-May-2006 03:22
I had trouble using IIS and PHP with Firefox. If you are having similar problems then take a look at this article: http://blogs.wdevs.com/shog9/archive/2005/03/09/2668.aspx emzeperx at emzeper dot hu
01-Jan-2006 12:36
01-Jan-2006 12:36
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. JUSTANOTHERUSER
14-Aug-2005 11:23
14-Aug-2005 11:23
<LimitExcept GET POST>
Deny from all
</LimitExcept>
Does not work with Apache2+ & PHP5 . Apache Refuses to start per dot fikse at ipj dot no
12-Jul-2005 01:22
12-Jul-2005 01:22
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) patrick hat paddyworks dot com
23-May-2005 09:52
23-May-2005 09:52
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. vlad at vkelman dot com
01-Mar-2005 08:45
01-Mar-2005 08:45
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. barry dot fagin at usafa dot af dot mil
04-Jan-2005 09:22
04-Jan-2005 09:22
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 furrycod at hotmail dot com
07-Sep-2004 09:35
07-Sep-2004 09:35
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. masternuthin diespammer at yahoo dot com
23-Jun-2004 03:33
23-Jun-2004 03:33
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. jeff_graham at datacenterservices dot net
01-Feb-2004 01:51
01-Feb-2004 01:51
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) nigel dot salt at hotmail dot com
13-Dec-2003 05:00
13-Dec-2003 05:00
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 jimo at mail dot azhsv dot com
29-Nov-2003 07:33
29-Nov-2003 07:33
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) peter dot mosinskisNOSPAM at csuci dot edu
06-Mar-2003 12:36
06-Mar-2003 12:36
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 monroe at peoplego dot com
17-May-2002 10:32
17-May-2002 10:32
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 rodent at mighty dot co dot za
17-Apr-2002 04:46
17-Apr-2002 04:46
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. tanis22 at hotmail dot com
12-Nov-2001 11:01
12-Nov-2001 11:01
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 rggonzalez at iname dot com
09-Nov-2000 05:40
09-Nov-2000 05:40
Notes on installing PHP (3.x.x or 4.x.x) on a RedHat 6.x Linux box using glibc 2.1.x. When you install it as a DSO module for Apache (--with-apxs) with the standard RPM's from RedHat for Apache and MySQL, the httpd daemon dies without giving any error message, and without sending any message to the console.
From a comment by Rasmus Ledorf: this is caused "probably due to a glibc-2.1.x bug related to dynamically loading a library
linked against pthreads into a binary that isn't linked against
pthreads. Try it using --without-mysql and see if it works. If it does
then you know it is a mysql-related problem. To fix it you will need the
non-threaded mysql client rpm available from www.mysql.com".
You can also download the source code for MySQL and recompiled it statically, using this configuration options:
--with-client-ldflags=-all-static
--with-mysqld-ldflags=-all-static
You must then re-run the ./configure; make; make install in your PHP source tree to get the PHP shared module working with the new MySQL support.
Regards,
Rodolfo Gonzalez.
rggonzalez@iname.com fischer_dj at mailcity dot com
24-Aug-2000 09:29
24-Aug-2000 09:29
I've added detailed PWS, Perl, & PHP4 installation instructions for Win98 at FAQts.
http://www.faqts.com/knowledge-base/view.phtml/aid/5495/fid/336/lang/en
"쇼핑몰·홈페이지·오픈마켓
블로그·페이스북·이메일 등의 각종 마케팅 글쓰기, 각종 광고, 영업, 판매, 제안서, 전단지 반응율 3배×10배 이상 높이는 마법의 8단계 공식" |
|
| ☞자세히보기 |
|
|
|
