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
