Re: Squid-3.2 status update

On 17.07.2012 13:30, Eliezer Croitoru wrote:
> On 7/5/2012 4:18 AM, Alex Rousskov wrote:
>> On 07/04/2012 05:34 PM, Amos Jeffries wrote:
>>> On 05.07.2012 10:00, Alex Rousskov wrote:
> <SNIP>
>>> It does that now. The "no harm" means we can't re-write the request
>>> headers to something we are not sure about and would actively cause
>>> problems if we got it wrong.
>>> The current state is that Squid goes DIRECT, instead of through
>>> peers.
>>> Breaking interception+cluster setups.
>>
>> That last part means "do harm" to those admins who discover
>> nonworking
>> setups that used to work fine (from their perspective). I understand
>> that your definition of "harm" may be different from theirs. This
>> conflict should be resolved by configuration knobs IMO.
>>
>>
>>> cache_peer relay is almost completely "disabled" for some major
>>> sites.
>>> Everything else works well.
>>
>> Well, we can wait for somebody to complain about that and then
>> decide
>> what to do, I guess. With some luck, nobody will complain.
>>
>> I certainly do not insist on treating this issue as a blocker for
>> v3.2
>> "stable" designation; only suggesting ways to close it.
>>
> +1
> not a developer but if a cache_peer cannot be accessed on an
> intercept mode it's pretty nasty.
>
> is there any way to make a "cache_peer" work in intercept mode at
> all? or it's a fatal bug that awaits to be fixed?
>

There is a way. We need to wrap a CONNECT request around the relayed
HTTP/1.1 request. Such that the CONNECT holds the original intercepted
ip:port details.
  -> "old" proxies can be trusted to tunnel straight to ORIGINAL_DST and
safely not be cache-poisoned.
  -> "new" proxies can be made to bump the CONNECT request when
Upgrade:HTTP/1.1 is present and treat them to the special handling they
deserve.

Just a bit tricky to implement, and I have not had much time yet.

And no, I'm not happy calling Squid-3.2 ready for stable release until
at least the CONNECT wrappers are being done.

Amos
Received on Tue Jul 17 2012 - 02:08:28 MDT