ID: 19113
User updated by: php at jdc dot parodius dot com
Reported By: php at jdc dot parodius dot com
Status: Open
Bug Type: Apache related
-Operating System: any
+Operating System: FreeBSD
-PHP Version: 4.3.0
+PHP Version: 4.3.1
New Comment:
Confirmed to exist using PHP 4.3.1 on FreeBSD 4.7-STABLE,
4.8-PRERELEASE, and 5.0-CURRENT.
I am appalled that this bug has not been escallated to the Critical or
Severe status, especially when it has been verified by a PHP developer
(01/05/2003; nohn at php dot net).
Previous Comments:
------------------------------------------------------------------------
[2003-03-06 10:47:22] keitaro at attbi dot com
Confirmed this with PHP 4.3.1 on Apache 1.3.27, RH7.3 distro.
--quote-start--
I was now able reproduce this problem, but only in case when index.php
was in DocumentRoot of first defined name-based virtual server (which
is
accepted as the default on that IP/port in such case), and index.php
was
the default script to execute (if there was something before index.php
in DirectoryIndex and if it also existed in DocumentRoot of the
default
vhost, the bug did not apply).
--quote-ends---
Problem seem to exist on this scenario. Did a fresh tarball install of
PHP 4.3.1 and tested it before and after PHP while having an index.html
in the root folder. Then I put in a small and simple index.php and got
the bug reproduced. Resorted to using Limit CONNECT workaround. Would
like to see this bug fixed ASAP.
------------------------------------------------------------------------
[2003-02-06 14:03:45] fearphage at hotmail dot com
Im not sure how or why but apache sends a 200 (ok) back from requests
for files that do not exist. I do not know how to rememedy this.
------------------------------------------------------------------------
[2003-01-22 05:14:24] karabass at mitino dot ptt dot ru
It *is* severe because when I see in apache access_log a message like
this:
24.153.155.146 - - [22/Jan/2003:01:25:48 +0300] "CONNECT
maildelivery.somewhere:25 HTTP/1.0" 200 44623 "-" "-"
it is threatening enough for me to put away what I was doing and start
staring at my httpd.conf. And that only takes 3-4 hours to just find
this bug-report and make myself comfortable about this new "PHP
feature".
------------------------------------------------------------------------
[2003-01-19 04:57:37] [EMAIL PROTECTED]
Well can you tell me why it is "severe"?
Okay it is maybe not correct that it reacts on any string
but basicly why should it not react on
TINTE / HTTP/1.0
This could be a valid request if the server has loaded
mod_tinte v1.0 or whatever. If you dislike the feature
you can always check for a valid ("from your point of
view") request method from within your scripts.
------------------------------------------------------------------------
[2003-01-18 20:33:41] php-bug-db at deuxchevaux dot org
This problem seems more severe than reported here, at least in 4.1.3
with Apache 1.3.26 shipped with Debian GNU/Linux 3.0.1: If mod_php4 is
enabled, any (!) string (try "foobar\n\n" instead of "GET /
HTTP/1.0\n\n") will return the home page from $DOCUMENT_ROOT/index.php.
If we comment out the LoadModule directive for mod_php4, the server
returns correctly "501 method not implemented".
Interestingly we couldn't reproduce it on an Apache 1.3.26 with PHP
4.2.2, but this may be because of the tested virtual host is not the
first one in the httpd.conf.
We noticed this while trying to figure out why the Apache answered to
requests like "\xe3P" (probably trying to exploit some bugs in some
webserver) with "200 OK" instead of "501 method not implemented".
An example:
With mod_php4:
> telnet our_host 80
Trying ###.###.###.###...
Connected to our_host.
Escape character is '^]'.
\xe3P
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML>
<HEAD>
<TITLE>our_host home page</TITLE>
</HEAD>
[...]
Without mod_php4:
> telnet our_host 80
Trying ###.###.###.###...
Connected to our_host.
Escape character is '^]'.
\xe3P
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>501 Method Not Implemented</TITLE>
</HEAD><BODY>
<H1>Method Not Implemented</H1>
\xe3P to /index.php not supported.<P>
Invalid method in request \\xe3P<P>
<HR>
<ADDRESS>Apache/1.3.26 Server at our_host Port 80</ADDRESS>
</BODY></HTML>
Connection closed by foreign host.
Maybe also interessting: A very long string (e.g. 80.000 characters)
correctly leads to an error "414 Request-URI Too Large", equal if
mod_php4 is loaded or not.
This looks like mod_php4 handles any possible request method, which is
passed to it. Is this really the wanted behaviour? Why should PHP
change Apache's behaviour in such cases?
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/19113
--
Edit this bug report at http://bugs.php.net/?id=19113&edit=1
