Re: [PATCH] Plain Surrogate/1.0 support

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