On 05/29/2013 04:40 AM, Amos Jeffries wrote: > You cannot (yet) configure sending a CONNECT to peers because nobody has > coded Squid to support that yet. I think it is worse: You can configure it, but it will not work in some cases. > There is some code in the very latest > Squid (as in it literally just went into 3.HEAD yesterday) Do you mean "[PATCH] Support forwarding intercepted but not bumped connections to cache_peers"? If yes, that proposed change is currently awaiting squid-dev review and has not been committed yet. Comments and testers welcome! > to make > failover send and handle CONNECT to peers when intercepted HTTPS goes > badly. But that is only for intercepted SSL at present. The pending patch is for handling non-bumped traffic so it does not cover cases where something went wrong, only cases where the admin configured Squid not to bump the intercepted [SSL] connection. There are indeed many other cases here, and some of them do not seem to work, but I have not studied that in detail as most early SslBump adopters were not using cache peers. The whole problem space has about 18 cases: (port: forward or intercept) x (bump: client-first, server-first, or none) x (peer: direct, plain cache_peer, ssl cache_peer). AFAIK, current Squid support includes: forward-none-direct, forward-none-plain, and intercept-none-direct. Our patch posted to squid-dev covers intercept-none-plain. We are also working on covering forward-none-ssl. Cheers, Alex.
