which case requests
would be encrypted, after all.
I think that condition shouldn't include `cache_peer`s with ssl.
*Mihai Ene*
Software Developer
*UB | Your universal basket*
http://ub.io
m...@ub.io
@shop_ub
+44 (0)7473 804972 <+447473804972>
On Thu, Jul 21, 2016 at 6:51 AM, Am
` output on line 819 in my logs when
testing with an ssl enabled cache_peer.
*Mihai Ene*
Software Developer
*UB | Your universal basket*
http://ub.io
m...@ub.io
@shop_ub
+44 (0)7473 804972 <+447473804972>
On Wed, Jul 20, 2016 at 1:32 PM, Amos Jeffries wrote:
> On 20/07/2016 2:37 a.m.,
t the procedure either seems too complicated, or the `man` pages
aren't the place. Anyway, contributing should be a separate thread.
Can a maintainer confirm that `cache_peer` does not work with `ssl_bump`ed
traffic, even when `ssl` option is used?
*Mihai Ene*
Software Developer
*UB | Your univer
ption is
mandatory when the peer is being used after an `ssl_bump`.
Thank you for all your help, i've learned a lot :)
*Mihai Ene*
Software Developer
*UB | Your universal basket*
http://ub.io
m...@ub.io
@shop_ub
+44 (0)7473 804972 <+447473804972>
On Tue, Jul 19, 2016 at 7:54 AM, A
` assertion (bug linked above), also considering the fact that
squid :8000 using itself as a proxy :8443 complains about a proxy loop, are
there any other options I might have to use ssl_bump *with* multiple
cache_peer, and cache_peer selection based on proxy_auth and/or req_header?
*Mihai Ene*
headers of the
bumped request?
If there's nothing I can do about this, is there a way to set the
ssl_bumped cache_peer based on the earlier proxy_auth username?
*Mihai Ene*
Software Developer
*UB | Your universal basket*
http://ub.io
m...@ub.io
@shop_ub
+44 (0)7473 804972 <+447473804
en bumping ssl? Or is it a bug?
*Mihai Ene*
Software Developer
*UB | Your universal basket*
http://ub.io
m...@ub.io
@shop_ub
+44 (0)7473 804972 <+447473804972>
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-ca
