Re: [PATCH] HTTP Compliance: Do not forward adapted TRACE with Max-Forwards: 0

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Wed, 09 Mar 2011 14:56:05 +1300

 On Tue, 08 Mar 2011 10:53:43 -0700, Alex Rousskov wrote:
> HTTP Compliance: Do not forward adapted TRACE with Max-Forwards: 0.
>
> Before the change, Max-Forwards request header value was cached using
> the HttpRequest::max_forwards member. The cache was initialized once
> in
> clientProcessRequest() function. That worked fine as long as no
> request
> adaptation was performed. Adaptation could replace the original HTTP
> request with the adapted one, losing the max_forwards value.
>
> This change removes the HttpRequest::max_forwards member and gets the
> header value directly from the HttpHeader object as needed. This
> means
> we may do a few more string-to-integer conversions for TRACE and
> OPTIONS
> requests, but the overhead is negligible and is probably a tiny net
> win
> for the common case.
>
> The no-cache approach also works better with eCAP adapters that may
> modify Max-Forwards.
>
>
> Removed assertion from clientReplyContext::traceReply() since the
> method
> is called from a single place and the condition is checked right
> before
> the call.
>
> Co-Advisors test cases:
> test_case/rfc2616/maxForwardsZero-TRACE-asterisk
> test_case/rfc2616/maxForwardsZero-TRACE-absolute
>
>
> Alex.

 Abort. This is already in trunk, 3.2, 3.1 since Nov 2010.
 http://master.squid-cache.org/Versions/v3/3.HEAD/changesets/squid-3-11046.patch

 Amos
Received on Wed Mar 09 2011 - 01:56:08 MST

This archive was generated by hypermail 2.2.0 : Wed Mar 09 2011 - 12:00:04 MST