On 13/11/2015 10:16 p.m., Edouard Gaulué wrote: > Hi Amos and all, > > Learning on HTTP CONNECT, I got > there:http://serverfault.com/questions/727262/how-to-redirect-https-connect-request-with-squid-explicit-proxy > > > I read on http://wiki.squid-cache.org/Features/MimicSslServerCert in the > "Delayed error responses" chapter: > "When Squid fails to negotiate a secure connection with the origin > server and bump-ssl-server-first is enabled, Squid remembers the error > page and serves it after establishing the secure connection with the > client and receiving the first encrypted client request. The error is > served securely. The same approach is used for Squid redirect messages > configured via deny_info. This error delay is implemented because (a) > browsers like FireFox and Chromium do not display CONNECT errors > correctly and (b) intercepted SSL connections must wait for the first > request to serve an error." > > My ideas/questions: > 1/ Is there a way to have the same with new peek and splice feature? Not really because CONNECT is not a part of TLS. It is a HTTP message. > 2/ Is there a way to say url_rewrite_program not to work on CONNECT > request? http://www.squid-cache.org/Doc/config/url_rewrite_access/ This way the CONNECT is not redirected, next request the > browser sends after squid has bumped it should be a kind of GET/POST > one that will be redirected by url_rewrite_program. > 3/ Would it works if squidguard were i-cap'ed? All SquidGuard does is apply some basic ACL rules to the details it is given by Squid. You would be far better off simply converting the SG rulset into http_access ACLs. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
