ID: 19113
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Apache related
Operating System: any
PHP Version: 4.3.0
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2003-01-18 20:33:41] [EMAIL PROTECTED]
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?
------------------------------------------------------------------------
[2003-01-05 07:41:37] [EMAIL PROTECTED]
Verified in Apache 1.3.27/Linux/PHP 4.3.0
------------------------------------------------------------------------
[2003-01-04 16:48:32] [EMAIL PROTECTED]
Yes; [EMAIL PROTECTED] is correct. My previous comment ("bug possibly
fixed") was in haste.
The problem still exists in 4.3.0. Please, someone in the PHP crew
investigate this fully, as it's becoming more and more of an issue and
seems to be affecting essentially everyone who uses PHP and Apache.
------------------------------------------------------------------------
[2003-01-03 23:39:16] [EMAIL PROTECTED]
Problem still exists in PHP 4.3.0, i'm running Apache 1.3.27 on
FreeBSD.
------------------------------------------------------------------------
[2003-01-02 06:32:47] [EMAIL PROTECTED]
I apologise for not being able to test 4.3.0 or any of the "snap"
releases prior to now -- we use FreeBSD, and we rely on the FreeBSD
port of mod_php4. The port author has not upgraded to 4.3.0 yet, and
therefore we were stuck using 4.2.3 until earlier this evening when I
removed the port and went with the old method of installing off source
manually.
It seems that this problem may in fact be fixed in 4.3.0. The problem
documented no longer appears.
------------------------------------------------------------------------
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
