On 18/06/2019 13:15, Amos Jeffries wrote:
On 17/06/19 11:46 pm, Charlie Orford wrote:
Annoyingly, one of our upstream cache_peers requires a fixed string to
be prepended to client usernames.
What type of fixed string exactly?
It's a special meaning string to control how that peer i
On 18/06/2019 06:01, ngtech1...@gmail.com wrote:
I believe that eCAP or ICAP can do the trick for you.
However I am not sure if it’s a good thing to pass usernames and
password in WWW Http requests.
Eliezer
*From:*squid-users *On
Behalf Of *Charlie Orford
*Sent:* Monday, June 17, 2019 2
Annoyingly, one of our upstream cache_peers requires a fixed string to
be prepended to client usernames.
I'm aware the login= option for cache_peer allows substituting * with
client provided username and appending a fixed string to this.
Is there a way to achieve something similar if we need
On 28/01/2017 17:47, Alex Rousskov wrote:
Our design goal is: intercept and bump local client https traffic on
squid1 (so we can filter certain urls, cache content etc.) and then
forward the request on to the origin server via an upstream squid2
(which has internet access).
Understood. Squid c
On 27/01/2017 23:43, Alex Rousskov wrote:
On 01/27/2017 04:04 PM, Charlie Orford wrote:
A post from another user on this list seems to suggest they successfully
got squid to do what we want
(http://lists.squid-cache.org/pipermail/squid-users/2015-November/007955.html)
but when emulating their
_DOMAIN on the cache_peer directive has no
effect.
Connecting to squid1 with a proxy aware client (on a standard http_port
with the ssl-bump flag set but no intercept) also results in the same
problem.
Where are we going wrong?
Charlie
On 27/01/2017 18:24, Charlie Orford wrote:
Hi list
W
Hi list
We're using squid 3.5.23 and trying to achieve the following:
client https request (not proxy aware) -> squid1 (https NAT intercept)
-> upstream squid2 (configured as a cache_peer in squid1) -> origin
server (e.g. www.google.com)
Amos mentioned in this thread
http://lists.squid-cach
