ID: 31717 Updated by: [EMAIL PROTECTED] Reported By: stijn at win dot tue dot nl -Status: Assigned +Status: Closed Bug Type: Apache2 related Operating System: FreeBSD 4 and -CURRENT PHP Version: 4.3.10 Assigned To: jorton New Comment:
This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Thanks, that wasn't quite right in a few ways, I've committed the patch I had in my tree... Previous Comments: ------------------------------------------------------------------------ [2005-03-03 12:50:17] stijn at win dot tue dot nl Here is a patch that is *VERY* lightly tested, but which appears to do the right thing for me (I don't see a place to upload a patch in this bug tracker, so I copy & paste this; beware of whitespace changes). %%% --- sapi/apache2handler/sapi_apache2.c.orig Mon Dec 6 19:55:16 2004 +++ sapi/apache2handler/sapi_apache2.c Thu Mar 3 12:46:03 2005 @@ -471,6 +471,12 @@ return DECLINED; } + /* check if we can accept PATH_INFO according to apache config */ + if (r->used_path_info == AP_REQ_REJECT_PATH_INFO + && strlen(r->path_info) != 0) { + return HTTP_NOT_FOUND; + } + if (r->finfo.filetype == 0) { php_apache_sapi_log_message_ex("script '%s' not found or unable to stat", r); zend_try { %%% What do you think? ------------------------------------------------------------------------ [2005-01-28 06:37:22] [EMAIL PROTECTED] It doesn't make sense to me that this is the responsibility of the handler. I see by looking at the code that it is, but it doesn't seem like a valid place for this to happen. If you configure Apache to not honour path_info then Apache shouldn't trigger the handler on the partial path. ------------------------------------------------------------------------ [2005-01-27 19:37:51] [EMAIL PROTECTED] Yes it does, in 2.0 the handler has to honour the r->used_path_info setting appropriately. ------------------------------------------------------------------------ [2005-01-27 18:08:01] [EMAIL PROTECTED] This has nothing to do with PHP and please don't post support questions to the bug database. ------------------------------------------------------------------------ [2005-01-27 11:23:03] stijn at win dot tue dot nl Description: ------------ I'm trying to turn the support for PATH_INFO off on a *default* install of apache-2.0.52 and php-4.3.10, but it doesn't work. Note that I am not 100% sure that this is a PHP bug, however Apache does not accept PATH_INFO for regular HTML files so I'm inclined to suspect PHP. I first installed Apache in a scratch directory: ./configure --prefix=/var/tmp/apachephp --enable-so --with-mpm=prefork --enable-maintainer-mode gmake gmake install Then PHP: env CFLAGS=-g ./configure --prefix=/var/tmp/apachephp --with-apxs2=/var/tmp/apachephp/bin/apxs --disable-cgi --disable-path-info-check gmake gmake install I edited /var/tmp/apachephp/conf/httpd.conf and added these lines: %%% AddType application/x-httpd-php .php AcceptPathInfo off <Directory /var/tmp/apachephp/htdocs> AcceptPathInfo off </Directory> %%% Adding a simple index.php to the docroot (/var/tmp/apachephp/htdocs/index.php): %%% <? phpinfo(); ?> %%% After starting httpd, I can still browse to http://localhost/index.php/foo/bar and see that PATH_INFO indeed contains /foo/bar. I've tried digging in the sources but I'm not familiar with Apache plugins. I did see this in gdb: %%% Breakpoint 2, php_apache_request_ctor (r=0x81b2050, ctx=0x81b3e70) at /local/home/stijn/tmp/php-4.3.10/sapi/apache2handler/sapi_apache2.c:408 408 SG(sapi_headers).http_response_code = !r->status ? HTTP_OK : r->status; (gdb) print r->path_info $1 = 0x81b3253 "/foo/bar" (gdb) print r->used_path_info $2 = 1 %%% So in the request constructor the path info is already set up? I did see something about overriding r->path_info for apache modules in the apache sources but here is where I cannot follow the code anymore... BTW, I tried to post this to php-general twice, but somehow my e-mail is blocked. I do hope this is not PEBKAC but even if it is I would be glad if someone pointed this out to me... Reproduce code: --------------- n/a Expected result: ---------------- n/a Actual result: -------------- see above for a maybe relevant backtrace snippet ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=31717&edit=1