You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe Jr." <wr...@rowe-clan.net> on 2012/03/20 22:28:41 UTC
Re: svn commit: r1302856 - /httpd/httpd/branches/2.4.x/docs/manual/mod/core.xml
On 3/20/2012 7:09 AM, jim@apache.org wrote:
> Author: jim
> Date: Tue Mar 20 12:09:05 2012
> New Revision: 1302856
>
> URL: http://svn.apache.org/viewvc?rev=1302856&view=rev
> Log:
> Merge r1302855 from trunk:
>
> Note that TRACE is not a vuln
Agreed.
> + <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
> + non-compliant.</p>
I'm not clear that's true.
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-19#section-6.8
currently in last call has plenty to say about TRACE. It doesn't document
a MUST requirement for a server to support TRACE requests. It reads (at
least to me, anyways) that support of TRACE is a good idea.
It has some comments on security implications, as well, in that document.
Re: svn commit: r1302856 - /httpd/httpd/branches/2.4.x/docs/manual/mod/core.xml
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/20/2012 4:28 PM, William A. Rowe Jr. wrote:
> On 3/20/2012 7:09 AM, jim@apache.org wrote:
>> Author: jim
>> Date: Tue Mar 20 12:09:05 2012
>> New Revision: 1302856
>>
>> URL: http://svn.apache.org/viewvc?rev=1302856&view=rev
>> Log:
>> Merge r1302855 from trunk:
>>
>> Note that TRACE is not a vuln
>
> Agreed.
>
>> + <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
>> + non-compliant.</p>
>
> I'm not clear that's true.
>
> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-19#section-6.8
> currently in last call has plenty to say about TRACE. It doesn't document
> a MUST requirement for a server to support TRACE requests. It reads (at
> least to me, anyways) that support of TRACE is a good idea.
>
> It has some comments on security implications, as well, in that document.
And looking at that document again, there is very little variation between
TRACE and DELETE to suggest that TRACE must be implemented, but that we
can leave DELETE unimplemented.
CONNECT, on the other hand, is very clear about how unlikely it is to be
implemented on origin servers.