Rev 2: [PATCH] 1.3 TraceEnable [on|off|extended]

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

The patch, in final form, tested and works for T-E with C-L > body, 
T-E with C-L < body, C-L only, T-E only and no body.  It correctly
denies proxy TRACE with a body by default, and will deny all TRACE
requests for 'TraceEnable off'.

Votes please, before I invest in patching 2.x?

A related message r.e. 2.x to follow.

Bill

At 01:30 AM 6/23/2005, William A. Rowe, Jr. wrote:

>The attached patch resolved the issue I noted below,
>10.4.6 405 Method Not Allowed requires an Allow header 
>(I would presume, even if empty, based on #() grammar),
>while 10.5.2 501 Not Implemented states;
>
>   This is the appropriate response when the server does not
>   recognize the request method and is not capable of supporting 
>   it for any resource.
>
>If 'ProxyEnable off' is set for a given host, the setting is
>url-impotent, and does not vary.
>
>Because the patch does append a new member to the core_server_config
>structure, it seems a minor bump is in order.
>
>
>At 12:52 PM 6/22/2005, William A. Rowe, Jr. wrote:
>
>>FYI there is one small issue still.  The resulting Allow: <null>
>>response to denied TRACE request.  TRACE doesn't go through the
>>normal processing, so methods aren't added.  And since TRACE is
>>denied, it's removed too.
>
>At 08:56 AM 6/22/2005, William A. Rowe, Jr. wrote:
>>I've spent a large number of cycles investigating the Watchfire report 
>>(http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf) and
>>come up with a genuine reason to adopt the attached patch.
>>...
>>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.

Re: Rev 2: [PATCH] 1.3 TraceEnable [on|off|extended]

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 04:27 PM 6/23/2005, Roy T. Fielding wrote:
>On Jun 23, 2005, at 6:53 AM, William A. Rowe, Jr. wrote:
>
>>The patch, in final form, tested and works for T-E with C-L > body,
>>T-E with C-L < body, C-L only, T-E only and no body.  It correctly
>>denies proxy TRACE with a body by default, and will deny all TRACE
>>requests for 'TraceEnable off'.
>>
>>Votes please, before I invest in patching 2.x?
>
>The correct response code to send is 403 Forbidden, not 405,
>since the method is being handled. That will simplify your
>patch considerably.

That still begs the question, if ap_die is called with the
error 405 should we return 'Allow:' with no tags, or drop
the Allow: header altogether.  In the past, this would have
been the almost equally absurd 'Allow: TRACE' alone, but with
the patch, we might not even have that.

It still seems the edge case exists.

>I have submitted a change request for s/MUST/MAY/ in the text of
>2616's definition of 405, since the Allow header field should not
>be required.

+1 thanks!

Bill

Re: Rev 2: [PATCH] 1.3 TraceEnable [on|off|extended]

["Roy T. Fielding" <fi...@gbiv.com>]

On Jun 23, 2005, at 6:53 AM, William A. Rowe, Jr. wrote:

> The patch, in final form, tested and works for T-E with C-L > body,
> T-E with C-L < body, C-L only, T-E only and no body.  It correctly
> denies proxy TRACE with a body by default, and will deny all TRACE
> requests for 'TraceEnable off'.
>
> Votes please, before I invest in patching 2.x?

The correct response code to send is 403 Forbidden, not 405,
since the method is being handled. That will simplify your
patch considerably.

I have submitted a change request for s/MUST/MAY/ in the text of
2616's definition of 405, since the Allow header field should not
be required.

....Roy