On Wednesday 21 March 2012, William A. Rowe Jr. wrote: > On 3/21/2012 2:59 PM, Mark Montague wrote: > > On March 21, 2012 15:33 , "Roy T. Fielding" <field...@gbiv.com> wrote: > >> TRACE won't work at all if the most popular end-point doesn't > >> support it. > > > > Why would this be a bad thing? Or, to phrase it another way, > > what are the situations in which it is desirable that TRACE be > > already-enabled on a web server as opposed to having the owner > > of the web server enable the TRACE method in response to a > > specific debugging need? > > Because, if you do NOT own the end-point, but are trying to debug a > fault in a proxy which you DO own, then the lack of support in the > upstream proxies or origin server leave you no ability to perform > this diagnostic.
But one thing that would be very interesting in this case, namely the X-Forwarded-For header, is something that most admins of a reverse- proxied site do NOT want to disclose at the end-point. They may also not want to reveal other headers sent from the reverse proxy to the end-point. > The output was never intended for unfiltered display. IIS provided > for the TRACE results to be emitted to the browser with no > consideration to cross-site scripting implications. There WAS a > browser bug, but never an actual flaw with the protocol or Apache > implementation. That's beside the point. I completely agree that TRACE is not a flaw in the protocol or server implementation. But it makes exploitation of some other vulnerabilities easier, be it bugs in browsers, browser plugins, request splitting bugs in proxies, or whatever. That's enough reason not to enable it by default, IMNSHO. > Most of the security reports and scanner output > mischaracterizes the original defect. I do agree that the security reports often exaggerate the severity of having TRACE enabled.
