Re: [PATCH] Plain Surrogate/1.0 support

[Amos Jeffries]

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


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