Re: [PATCH] Plain Surrogate/1.0 support

[Amos Jeffries]

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