Amos Jeffries wrote:
Robert Collins wrote:
On Sun, 2010-02-07 at 00:52 +1300, Amos Jeffries wrote:
According to the W3C documentation the Surrogate/1.0 capabilities and
the Surrogate-Control: header are distinct from the ESI capabilities.
This patch makes Squid always advertise and perform the Surrogate/1.0
capabilities for reverse-proxy requests.
Full ESI support is no longer required to use the bare-bones
Surrogate-Control: capabilities.
A quick check though - is it still only enabled for accel ports? (It
shouldn't be enabled for forward proxying).
-Rob
Yes. That restriction is still in effect.
The substantial changes are removing the #if ESI from around the
relevant bits of code, and altering the Surrogate-Capability text not to
mention ESI unless ESI is also present.
The new code is for stripping off Surrogate-Control as a scoped
hop-by-hop header unless Surrogate-Capability has itself been explicitly
received from upstream surrogates. This is done regardless of mode to
cope with cases like client->surrogate->forward->server and
client->forward->surrogate->forward->server and
client->surrogate->surrogate->server
Oops, sorry. No that is not done in any mode. ... but should be. Will
fix for the commit.
The remaining two issues that will need fixing one day are:
requests arriving in a forward-proxy port and being redirected out to
reverse-proxy peers due to their actual destination. These will not have
surrogate advertised. The resulting object may or may not interfere with
objects being stored by the surrogate-control.
stripping out only the current instances surrogate-id bits from the
control header and passing on just the remaining bits to upstream
surrogates. This is not done, so there is some information leakage when
upstream send surrogate-capability.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE7 or 3.0.STABLE23
Current Beta Squid 3.1.0.16
