https://bz.apache.org/bugzilla/show_bug.cgi?id=70264
Bug ID: 70264
Summary: mod_dav advertises TRACE in Allow when TraceEnable is
off
Product: Apache httpd-2
Version: 2.5-HEAD
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: mod_dav
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
With TraceEnable off, mod_dav still advertises TRACE in the Allow header
returned by OPTIONS for existing DAV resources.
For example:
TraceEnable off
DAV On
An OPTIONS request to an existing DAV resource returns an Allow field
containing TRACE:
OPTIONS,GET,HEAD,POST,DELETE,TRACE,PROPFIND,PROPPATCH,COPY,MOVE,PUT,LOCK,UNLOCK
but an actual TRACE request to the same resource is rejected with 405 because
TRACE is disabled by server configuration.
This is inconsistent with the semantics of the Allow field in RFC 9110 section
10.2.1, which describes the methods advertised as supported by the target
resource and notes that the allowed set is determined at the time of each
request.
The cause is in dav_method_options(): mod_dav constructs its own Allow field
and unconditionally adds TRACE for existing resources. This code predates the
TraceEnable directive.
The generic OPTIONS implementation already omits TRACE when TraceEnable is off;
mod_dav bypasses that implementation by constructing its own Allow header.
Reproduced on current trunk f6b14daf42.
Controls:
* TraceEnable off: DAV OPTIONS advertises TRACE, actual TRACE returns 405.
* TraceEnable on: DAV OPTIONS advertises TRACE and TRACE succeeds.
* TraceEnable extended: same as on.
* Static OPTIONS correctly omits TRACE when disabled.
I have a small patch and regression tests which make mod_dav add TRACE only
when TraceEnable is not disabled.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
