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?
Eliezer
Cheers,
Alex.
--
Eliezer Croitoru
https://www1.ngtech.co.il
IT consulting for Nonprofit organizations
eliezer <at> ngtech.co.il
