ID: 32561 Updated by: [EMAIL PROTECTED] Reported By: mnot at pobox dot com Status: Assigned Bug Type: Apache related Operating System: * PHP Version: 5.*, 4.* Assigned To: rasmus New Comment:
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. Previous Comments: ------------------------------------------------------------------------ [2005-12-22 22:11:01] [EMAIL PROTECTED] Rasmus, are you planning on doing anything about this? ------------------------------------------------------------------------ [2005-10-20 00:32:28] 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-09-21 12:51:15] [EMAIL PROTECTED] Assigned to Rasmus who should know what to do with this bug. ------------------------------------------------------------------------ [2005-04-24 00:00:26] [EMAIL PROTECTED] This was added in PHP 3, by Rasmus with this commit msg: "AAPI cleanup - Set rqst->allowed correctly and deny OPTIONS requests" ------------------------------------------------------------------------ [2005-04-04 18:41:12] 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. ------------------------------------------------------------------------ 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/32561 -- Edit this bug report at http://bugs.php.net/?id=32561&edit=1