I believe the following to be a severe bug which relates directly to
PHP4 and Apache 1.3:

For those of you unfamiliar with HTTP, there is an HTTP command called
"CONNECT" which is intended for use with HTTP proxying. Via telnet, one
can test for proxy capability by doing the following (input is in bold):

$ telnet www.somehost.com 80
Trying ###.###.###.###...
Connected to www.somehost.com.
Escape character is '^]'.
CONNECT www.google.com:80 HTTP/1.0
Host: www.somehost.com

Now hit [Enter] twice. If your Apache configuration is proper (and
without mod_proxy installed), you should get the following response:

HTTP/1.1 405 Method Not Allowed

However, this is where the bug shows up.  Here are the pre-requisites
for it to appear:

Must have PHP4 module loaded. 
Must have index.php listed in Apache DocumentIndex directive.
Must have index.php file in the DocumentRoot of the website you're
connecting to (in the above example, www.somehost.com). 

The result of the above HTTP CONNECT when all of the above pre-requistes
are met:

HTTP/1.1 200 OK
[HTTP headers here]
[Contents of parsed index.php here; as if visiting the website!]

An HTTP response code of 200 should only be sent when the request was
legitimate -- a HTTP CONNECT should not be legitimate just because the
website in question has an index.php file. You can literally rename
index.php to something else (even index.html!) and a correct HTTP status
of 405 is returned.  I have read the HTTP RFC in full, and it is fairly
vague when it comes to dealing with HTTP CONNECT -- however, the Status
code section applies to all sections, therefore a Status code of 200 on
an HTTP CONNECT when mod_proxy is not loaded is incorrect.

Again, this only happens with mod_php4 installed.

So why is this a big deal?  Well, a slew of online services use proxy
scanners to ensure legitimate clients are being used to communicate with
their servers; proxy scanners are also used for IRC.  The scanners look
for a status code of 200 on an HTTP CONNECT.

There is a workaround, which is to add the following to your server
configuration: 

<Location />
  <Limit CONNECT>
    Order deny,allow
    Deny from all
  </Limit>
</Location>

This bug may be directly related to bug #17424.

Footnote: If this is traced back to be a flaw in Apache's DSO code, then
I expect to see it reported as such, so I can forward this entire thread
on to the Apache team and make them deal with it.  Thanks.

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.

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".

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.

See comment by: [16 Mar 6:40am CST] psi-jack at myrddincd dot com 

I added the following three lines to Apache's mod_dir. This is ugly but
works fine for me. Unless there's another way to prevent mod_php4 from
getting invoked I'll use this on my machines.
Dunno if this will work with mod_proxy but I guess so.

--- src/modules/standard/mod_dir.c
+++ src/modules/standard/mod_dir.c
@@ -118,4 +118,7 @@
 static int handle_dir(request_rec *r)
 {
+    if (r->method_number == M_CONNECT)
+        return HTTP_NOT_IMPLEMENTED;
+
     dir_config_rec *d =
     (dir_config_rec *) ap_get_module_config(r->per_dir_config,

Use it at your own risk and only with Apache 1.3(.28)!

I don't know the apache's interface to modules, But I think that either
php should tell apache by initialization that it can handle GET, HEAD,
and POST method, ot the php should
check whether it is able to process the method (CONNECT in this case) -
if it does have handler for it. 
I think that php does not have handler for CONNECT by default, thus it
should either reject the request or pass it to apache for later
processing.

mod_perl probably has the same bug, but unless apache does have an
interface for modules to specify which methods are they able to use AND
ignores the methods, it is a bug od mod_php versus mod_perl...

This bug still applies to PHP 5.x, apparently.  A user of mine just
recently asked me why his Apache logs were showing HTTP 200 status codes
with requests like "CONNECT" when mod_proxy isn't loaded, and I pointed
him to this bug.

Could a developer please look at this?  This bug is over 3 years old
(!).  Changing Status to Open...

Thanks.

Does this work for you too:
NOSUCHMETHOD / HTTP/1.0
?

Not PHP problem.

As mentioned a couple years ago, this may have gotten fixed somewhere
along the lines in Apache (or possibly PHP).

I just built a test system using FreeBSD 6.0, Apache 2.0.55, and PHP
5.1.1 (as a module) and *cannot* get this bug to appear.

But hear me out on this one if you could.  :-)

Reason I have a hard time believing it's an Apache bug: if it was an
issue with interpreted handlers (such as PHP and mod_perl -- see one of
the other users' comments), then I would also expect the exact same bug
to appear when using mod_include (for server-parsed HTML documents). 
But this doesn't happen.

Reason I have a hard time believing it's a PHP bug: because the problem
seems to have disappeared (at least on my test setup).  Also, because
one of the other users stated that he had the same problem with mod_perl
loaded (but not with mod_php).

So either this got fixed in a PHP update (possibly mod_perl is still
broken then!), or an Apache update (more than likely an Apache APR
update).

I'm not going to sift through 3 years of ChangeLogs for PHP and Apache
to try and track this down, especially since I don't keep up-to-date
with *every* ChangeLog entry.

I'm fine with this being kept in Bogus status, but if someone has ideas
as to how this got fixed (and more importantly, in where) then it'd be
great if they could chime in here.  I'd feel better knowing where this
bug was (Apache vs. PHP), rather than just some PHP developer telling me
"not a PHP problem".

Finally, I'm changing the OS to "All" because this problem had been
confirmed to exist on Win32 as well, not just UNIX.