php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #16515 Files with execute-bit are always php-parsed - I cannot disable this!
Submitted: 2002-04-09 11:06 UTC Modified: 2002-08-19 11:52 UTC
Votes:3
Avg. Score:3.7 ± 0.9
Reproduced:3 of 3 (100.0%)
Same Version:1 (33.3%)
Same OS:1 (33.3%)
From: swift at 3d4x dot de Assigned:
Status: Closed Package: Apache related
PHP Version: 4.1.2 OS: Linux 2.4.16
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: swift at 3d4x dot de
New email:
PHP Version: OS:

 

 [2002-04-09 11:06 UTC] swift at 3d4x dot de 
Hello!

After updating 4.04pl1 to 4.1.1, I encountered the following problem:
All .htm and .html-files with the execute-bit set, are PHP parsed! I disabled the xbithack-feature of Apache and phpinfo() tells me correctly, that xbithack is disabled (ok, the xbithack-feature will normally enable SSI-parsing in Apache, but I wanted to be sure that everything is disabled).

Then I updated to 4.1.2, but the files are still PHP-parsed.
I updated Apache from 1.3.19 to 1.3.22, but the files are still PHP-parsed.

I tried everything, but my xbit-files are still PHP-parsed - and I don't want this (sigh!). Is this a bug or a hidden feature?

Is there something I can do? Can anybody reproduce the problem? (just set chmod 755 for a .html-file, put some php-code in it and look if it is being PHP-parsed)

Help!
Thanks for your support.
Greetings ... tobias wiersch from germany

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-04-09 11:32 UTC] sander@php.net 
The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php

I'm sure this is a configuration issue; ask support on the appropriate mailinglist.
 [2002-04-10 09:05 UTC] sander@php.net 
Reopening on user request.
 [2002-04-10 12:24 UTC] swift at 3d4x dot de 
I discussed the problem already with Zeev (@Zend) some weeks ago and he wrote:

>I'm not sure what to tell you...  It's definitely not a
>known bug in PHP, I've never heard it being reported
>before ever.

So, please can anybody check this behaviour/bug? Please tell me if I can help somehow or test some config-params on my system.

Thank you very much.
 [2002-04-18 16:57 UTC] chef at bommel dot de 
I have the very same problem here regarding parsing of html files by the php module, if x-bit is set.

apache 1.3.23 with php 4.1.2 as apache module and XBitHack off running on FreeBSD 4.5-STABLE.
 [2002-04-23 17:32 UTC] earl dot fogel at usask dot ca 
I have the same problem, with php 4.1.2 and apache 1.3.6 on Solaris.

In some directories, php parses html files.  In others, mod_include parses them.  It seems that when I add any
php configuration directives to apache in per-directory
context, then php parses html files.

I've tried setting xbithack to Off in php.ini and in apache.conf, but it does not help.
 [2002-08-19 09:23 UTC] mjg17 at eng dot cam dot ac dot uk 
I'm having the same problem with PHP 4.2.1 on Red Hat Linux 7.2 under Apache 1.3.26.

It would seem that the xbithack option is being sensed as on, even though php_info() says it is turned off.

Could someone have a look at php_xbithack_handler() in sapi/apache/mod_php4.c?  I'm no PHP source expert, but I think that it's retrieving the wrong config info.

Other calls to get_module_config(r->per_dir_config,...) are cast to (HashTable *) in the same file.

Thanks

Michael
 [2002-08-19 11:52 UTC] rasmus@php.net 
Yeah, the code was bogus.  This is now fixed in CVS.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Apr 19 23:01:28 2024 UTC