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
