Re: svn commit: r290519 - /httpd/httpd/trunk/CHANGES

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

The RFC 2616 says

    The presence of a message-body in a request is signaled by the
    inclusion of a Content-Length or Transfer-Encoding header field in
    the request's message-headers. A message-body MUST NOT be included in
    a request if the specification of the request method (section 5.1.1)
    does not allow sending an entity-body in requests. A server SHOULD
    read and forward a message-body on any request; if the request method
    does not include defined semantics for an entity-body, then the
    message-body SHOULD be ignored when handling the request.

so I have no clue what

> +  *) Added TraceEnable [on|off|extended] per-server directive to alter
> +     the behavior of the TRACE method.  This addresses a flaw in proxy
> +     conformance to RFC 2616 - previously the proxy server would 
> accept
> +     a TRACE request body although the RFC prohibited it.  The default
> +     remains 'TraceEnable on'.  [William Rowe]

claims to be saying.  The proxy server SHOULD accept and forward
the message body and SHOULD ignore it.  Which means the options should
be on|off|rejectbody if you want to configure such behavior.

....Roy

Re: svn commit: r290519 - /httpd/httpd/trunk/CHANGES

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

Roy T. Fielding wrote:
> The RFC 2616 says
> 
>    The presence of a message-body in a request is signaled by the
>    inclusion of a Content-Length or Transfer-Encoding header field in
>    the request's message-headers. A message-body MUST NOT be included in
>    a request if the specification of the request method (section 5.1.1)
>    does not allow sending an entity-body in requests. A server SHOULD
>    read and forward a message-body on any request; if the request method
>    does not include defined semantics for an entity-body, then the
>    message-body SHOULD be ignored when handling the request.

Section 9.8 TRACE also says

    The TRACE method is used to invoke a remote, application-layer loop-
    back of the request message. The final recipient of the request
    SHOULD reflect the message received back to the client as the
    entity-body of a 200 (OK) response. The final recipient is either the
    origin server or the first proxy or gateway to receive a Max-Forwards
    value of zero (0) in the request (see section 14.31). A TRACE request
    MUST NOT include an entity.

> so I have no clue what
> 
>> +  *) Added TraceEnable [on|off|extended] per-server directive to alter
>> +     the behavior of the TRACE method.  This addresses a flaw in proxy
>> +     conformance to RFC 2616 - previously the proxy server would accept
>> +     a TRACE request body although the RFC prohibited it.  The default
>> +     remains 'TraceEnable on'.  [William Rowe]
> 
> claims to be saying.  The proxy server SHOULD accept and forward
> the message body and SHOULD ignore it.  Which means the options should
> be on|off|rejectbody if you want to configure such behavior.

If it's always fine for us to forward a TRACE request that includes an
entity body - let's do that.  The only 'extended' discrepancy is that,
as TRACE spells out that it echos the Headers, 'extended' also echos
a small entity (up to 64kb).

The 'bug' if I've read TRACE wrong, is that we should pass these TRACE
bodies on, unconditionally.  TraceEnable extended as the origin server
can continue to perform a body echo for those debugging the proxy or
filter configuration.

Thoughts/observations?

Bill