#19113 [Com]: HTTP status 200 returned on HTTP CONNECT when mod_proxy not in use

From: Date: Sun, 19 Jan 2003 02:33:42 +0000
Subject: #19113 [Com]: HTTP status 200 returned on HTTP CONNECT when mod_proxy not in use
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-30536@lists.php.net to get a copy of this message 
 ID:               19113
 Comment by:       php-bug-db@deuxchevaux.org
 Reported By:      php@jdc.parodius.com
 Status:           Open
 Bug Type:         Apache related
 Operating System: any
 PHP Version:      4.3.0
 New Comment:

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?


Previous Comments:
------------------------------------------------------------------------

[2003-01-05 07:41:37] nohn@php.net

Verified in Apache 1.3.27/Linux/PHP 4.3.0

------------------------------------------------------------------------

[2003-01-04 16:48:32] php@jdc.parodius.com

Yes; jon@steadyflow.net 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] jon@steadyflow.net

Problem still exists in PHP 4.3.0, i'm running Apache 1.3.27 on
FreeBSD.

------------------------------------------------------------------------

[2003-01-02 06:32:47] php@jdc.parodius.com

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.

------------------------------------------------------------------------

[2002-12-28 01:00:02] php-bugs@lists.php.net

No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

------------------------------------------------------------------------

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

Thread (49 messages)

« previous php.bugs (#30536) next »