#19113 [Opn]: HTTP status 200 returned on HTTP CONNECT when mod_proxy not in use
ID: 19113 User updated by: php_new at jdc dot parodius dot com -Reported By: php at jdc dot parodius dot com +Reported By: php_new at jdc dot parodius dot com Status: Open Bug Type: Apache related Operating System: FreeBSD PHP Version: 4.3.2-dev New Comment: Sorry, change of Email address. Previous Comments: [2003-06-03 15:07:22] php at jdc dot parodius dot com AFAIK, still applies to PHP 4.3.2. And who set this to Status Bogus? It's not bogus. It's a major faultpoint. [2003-05-31 02:30:15] jtrh at jtrh dot com Just installed php4-STABLE-latest.tar.gz and the problem continues. This bug has produced me hundreds of thousands of CONNECT x.x.x.x:25 HTTP/1.0 logs, and made the PHP counter on my index.php to go to a very high number. The Limit CONNECT fix showed here messed up my web server, allowing the reading of .htpasswd files. If someone knows where can I find a patch or a good configuration workaround please post it here, it will be of great help to many people. Thanks. [2003-03-16 10:59:02] [EMAIL PROTECTED] As per last comment..bogus. (I couldn't reproduce this, but then again, I don't have mod_perl..) [2003-03-16 06:40:23] psi-jack at myrddincd dot com I've been testing out all the comments mentioned in this report. The findings I have, is with Apache 1.3.27, and various modules. The modules I use is mod_php 4.3.0, mod_perl 1.27, mod_mp3 0.39, and for mod_perl, I had HTML-Mason and AxKit, and various other non-advertising mod_perl modules. What did I find? With all the mentioned modules loaded, I get the same results as mentioned within these comments. \xe3P TINTE / HTTP/1.0 CONNECT www.google.com:80 HTTP/1.0 Etc, all these, provide the default page, wether it's a DirectoryIndex, or directory listing itself. I unloaded mod_php, as per this bug was about. Still, same results. Once I unloaded mod_perl, however, the problem went away. I started getting 501's with those requests. mod_mp3 didn't seem to effect that at all. My final conclusion, this is very likely to be an Apache DSO bug, and not related directly to PHP, since it occured with mod_perl as well. The only one thing I did not try, was unloading my perlmodules from mod_perl. [2003-03-07 10:33:38] php at jdc dot parodius dot com Verified that the latest PHP -STABLE- snapshot does not fix this problem. I fully agree with what keitaro said; this kind-of software QA testing is ineffective. The problem is reproducable, and is _very_ easy to check for, especially since it happens out-of-the-box. I read the NEWS file every time I'm asked to test, just to see if there's anything which looks applicable -- and there never is. I've much respect for the PHP crew, but this style of testing is tedious. Please have a developer *investigate* this problem, rather than just throwing CVS builds at end-users every [X] days, hoping that some other bug was the cause of the problem. Heck, I'm still waiting to know if it's a problem with PHP or Apache! 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=19113edit=1
#19113 [Opn]: HTTP status 200 returned on HTTP CONNECT when mod_proxy not in use
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 TITLEour_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 HTMLHEAD TITLE501 Method Not Implemented/TITLE /HEADBODY H1Method Not Implemented/H1 \xe3P to /index.php not supported.P Invalid method in request \\xe3PP HR ADDRESSApache/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=19113edit=1
#19113 [Opn]: HTTP status 200 returned on HTTP CONNECT when mod_proxy not in use
ID: 19113 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache related Operating System: FreeBSD 4.6.2 PHP Version: 4.2.2 New Comment: 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. Previous Comments: [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. [2002-12-28 01:00:02] [EMAIL PROTECTED] 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. [2002-12-18 07:09:42] [EMAIL PROTECTED] Sorry, you don't understand the problem. The problem is that apache returns HTTP 200 OK on CONNECT request, but does NOT really connect to specified addrress. If it is possible to connect through your server to outside, then it's problem of your misconfigured proxy. [2002-12-16 13:54:03] [EMAIL PROTECTED] This bug is VERY serious. Our web servers have be attacked and used for relaying SPAM. Spammers are using the CONNECT command to proxy to open relay servers masking their IP addresses with ours. 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=19113edit=1
