We had a couple of people complaining about the language around TRACE in
the docs, which say disabling TRACE "makes your server noncompliant", a
claim I found hard to support.
All methods but HEAD and GET are defined as OPTIONAL, so I'm not sure
how this is true, am I missing something?
https://tools.ietf.org/html/rfc2616#section-5.1.1
https://tools.ietf.org/html/rfc7231#section-4.1
Is that choice of words just to scare people off? IIRC there are some
pretty strong opinions on this; attached is how I'd change it.
Index: docs/manual/mod/core.xml
===================================================================
--- docs/manual/mod/core.xml (revision 1750619)
+++ docs/manual/mod/core.xml (working copy)
@@ -4532,16 +4532,20 @@
<p>Finally, for testing and diagnostic purposes only, request
bodies may be allowed using the non-compliant <code>TraceEnable
extended</code> directive. The core (as an origin server) will
- restrict the request body to 64k (plus 8k for chunk headers if
+ restrict the request body to 64Kb (plus 8Kb for chunk headers if
<code>Transfer-Encoding: chunked</code> is used). The core will
reflect the full headers and all chunk headers with the response
body. As a proxy server, the request body is not restricted to 64k.</p>
<note><title>Note</title>
- <p>Despite claims to the contrary, <code>TRACE</code> is not
- a security vulnerability, and there is no viable reason for
- it to be disabled. Doing so necessarily makes your server
- noncompliant.</p>
+
+ <p>Despite claims to the contrary, enabling the <code>TRACE</code>
+ method does not expose any security vulnerability in Apache httpd.
+ The <code>TRACE</code> method is defined by the HTTP/1.1
+ specification and implementations are expected to support it.
+ Leaving <code>TRACE</code> enabled is strongly recommended for all
+ deployments of Apache httpd.</p>
+
</note>
</usage>
</directivesynopsis>
