You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2006/03/09 04:06:06 UTC
DO NOT REPLY [Bug 38903] New: - r->allowed is not considered
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38903>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38903
Summary: r->allowed is not considered
Product: Apache httpd-2
Version: 2.0.55
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: All
AssignedTo: bugs@httpd.apache.org
ReportedBy: lavr@ncbi.nlm.nih.gov
There is a "request_rec::allowed" member, which is documented like so
(in include/httpd.h, struct request_rec):
/**
* 'allowed' is a bitvector of the allowed methods.
*
* A handler must ensure that the request method is one that
* it is capable of handling. Generally modules should DECLINE
* any request methods they do not handle. Prior to aborting the
* handler like this the handler should set r->allowed to the list
* of methods that it is willing to handle. This bitvector is used
* to construct the "Allow:" header required for OPTIONS requests,
* and HTTP_METHOD_NOT_ALLOWED and HTTP_NOT_IMPLEMENTED status codes.
*
* Since the default_handler deals with OPTIONS, all modules can
* usually decline to deal with OPTIONS. TRACE is always allowed,
* modules don't need to set it explicitly.
*
* Since the default_handler will always handle a GET, a
* module which does *not* implement GET should probably return
* HTTP_METHOD_NOT_ALLOWED. Unfortunately this means that a Script GET
* handler can't be installed by mod_actions.
*/
apr_int64_t allowed;
But "Allow:" is never actually constructed out of this member (done
in http/http_protocol.c, by make_allow()):
/* Build the Allow field-value from the request handler method mask.
* Note that we always allow TRACE, since it is handled below.
*/
static char *make_allow(request_rec *r)
Naturally, this member is never referenced in this function,
nor in any other one across the entire package, except that it is
only _set_ by various modules as to how it is documented -- see above,
like for example in mod_status.c.
Thus, setting of r->allowed does not work, and only "Allow: TRACE" gets
returned in the response headers regardless of the value of r->allowed
when HTTP_METHOD_NOT_ALLOWED results from a handler.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 38903] - r->allowed does not affect Allow response header
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38903>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38903
asfbug@omni.poc.net changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|r->allowed is not considered|r->allowed does not affect
| |Allow response header
------- Additional Comments From asfbug@omni.poc.net 2007-03-30 08:01 -------
This is a real problem.
ap_send_http_options() looks at r->allowed_methods->method_mask, not r->allowed.
You can do something like this as a workaround:
... r->allowed_methods->method_mask = r->allowed;
... ap_send_http_options(r);
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org