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.
Received on Wed May 29 2013 - 14:44:41 MDT
This archive was generated by hypermail 2.2.0 : Wed May 29 2013 - 12:00:07 MDT