httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject [PATCH] 1.3 TraceEnable [on|off|extended]
Date Wed, 22 Jun 2005 13:56:12 GMT
I've spent a large number of cycles investigating the Watchfire report 
( and
come up with a genuine reason to adopt the attached patch.

One advantage of TRACE is to determine exactly what the server thinks
it just saw.  This is ideal for walking requests through proxies.

Unfortunately, TRACE does not support request bodies(*) (RFC2616 9.8;
"A TRACE request MUST NOT include an entity."), so it turned out 
to be somewhat useless, initially.  Supporting such behavior on
a very explicit basis (for testing the server or proxies, etc), since
proved to be very helpful for me.  (*) Note that 1.3, 2.0 and trunk
all support TRACE request bodies on proxied connections, the attached
patch also addresses this error.

Finally, after reviewing the report, I'm now convinced there is some
legitimate reason to deny TRACE if the administrator chooses.  Although
I don't subscribe to security by obscurity, too much transparency can
sometimes be a useful thing for exploit tools.  I still laugh at the
premise that TRACE 'caused' the IE xss vulnerabilities, of course.
Note that TRACE is not mandatory per RFC 2616 (only GET, HEAD are.)

So the attached patch introduces the per-host directive

TraceEnable on|off|extended

where extended permits a message body, up to 64kb at the target server,
and of an unlimited size through a proxy server.  The default remains
'on', of course, denying a TRACE body request even via proxy.

Following the semantics of TRACE, the request body is returned to the
host verbatim as part of the response, following the headers, exactly
as sent.

Patches will follow for 2.0 and trunk.  I have several days of other
work to catch up on, so won't jump on this till Friday eve.  Comments
on this patch before I start would be appreciated.


View raw message