php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #32561 Erroneous Allow HTTP response header
Submitted: 2005-04-04 05:19 UTC Modified: 2006-01-19 08:20 UTC
Votes:1
Avg. Score:4.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: mnot at pobox dot com Assigned: rasmus (profile)
Status: Closed Package: Apache related
PHP Version: 5.*, 4.* OS: *
Private report: No CVE-ID: None
 [2005-04-04 05:19 UTC] mnot at pobox dot com
Description:
------------
When using the Apache module, PHP installs the xbithack 
handler for text/html.

This handler make the following change to r->allowed, 
which is what Apache uses to populate the Allowed header 
on responses that require it (e.g., to OPTIONS, 405 
Method Not Allowed, 501 Not Implemented);
 
  r->allowed |= (1 << METHODS) - 1;

This has the affect of adding *all* known HTTP methods 
to the list. Effectively, PHP is telling clients that it 
can handle all HTTP methods, even for resources that 
aren't actually parsed as PHP.

This is also the case in php5.

Reproduce code:
---------------
mnot-laptop:~> telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
OPTIONS /index.html HTTP/1.1
Host: localhost

Expected result:
----------------
HTTP/1.1 200 OK
Date: Mon, 04 Apr 2005 03:12:29 GMT
Server: Apache/1.3.33 (Darwin) PHP/4.3.10
Cache-Control: max-age=3600
Expires: Mon, 04 Apr 2005 04:12:29 GMT
Content-Length: 0
Allow: GET, HEAD, OPTIONS, TRACE

Actual result:
--------------
HTTP/1.1 200 OK
Date: Mon, 04 Apr 2005 03:12:29 GMT
Server: Apache/1.3.33 (Darwin) PHP/4.3.10
Cache-Control: max-age=3600
Expires: Mon, 04 Apr 2005 04:12:29 GMT
Content-Length: 0
Allow: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, 
PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, 
UNLOCK, TRACE

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-04-04 07:25 UTC] rasmus@php.net
Actually, it resets the r->allowed to all the methods when it declines to handle the request for the next handler in the chain.  It probably doesn't need to do this, but it isn't unique to the xbithack handler.  Whatever finally accepts to handle the request should be setting r->allowed accordingly.
 [2005-04-04 18:41 UTC] mnot at pobox dot com
By doing that, it's saying that it would handle those 
methods in the future. If it won't, it shouldn't set 
that.

The downline handler *shouldn't* blow away r->allowed 
and put its own values in; this would remove any 
information from other handlers. E.g., if mod_cgi did 
this, mod_dav couldn't advertise the methods that it 
would catch.
 [2005-04-24 00:00 UTC] sniper@php.net
This was added in PHP 3, by Rasmus with this commit msg:
"AAPI cleanup - Set rqst->allowed correctly and deny OPTIONS requests"
 [2005-09-21 12:51 UTC] sniper@php.net
Assigned to Rasmus who should know what to do with this bug.
 [2005-10-20 00:32 UTC] mnot at pobox dot com
See also:
http://issues.apache.org/bugzilla/show_bug.cgi?id=15242
for resolution of a simliar bug in mod_cgi.
 [2005-12-22 22:11 UTC] sniper@php.net
Rasmus, are you planning on doing anything about this?
 [2006-01-06 19:16 UTC] rasmus@php.net
I have removed the code that messes with r->allowed in HEAD and in PHP_5_1 for now.  Let's see if this breaks anything.  I honestly don't recall why I thought it was important to set r->allowed this way on a declined request.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 19 06:01:29 2024 UTC