Hi Amos,
Thank you for your reply.
The information I need to apply to the header is client specific, ex their internal ip address.
The issue I am facing is that the network that is hosting the web services is different from the network that the clients are accessing it from. So my Squid instances live at the client site and they access the web services out of a data center.
I need to know the clients internal ip at the data center for a number of reasons. Therefore if I am understanding your suggestion correctly the reverse ssl proxy would not work as the squid reverse proxy needs to be on the same internal network/vlan as the destination host to function? http://wiki.squid-cache.org/ConfigExamples/Reverse/SslWithWildcardCertifiate
Essentially what I have is the clients internal ip at the client site, which with HTTP only used to allow me the pack the internal ip into the HTTP header via 'request_header_add'. Now, I still need to get the internal ip into the HTTPS request so that the web services can operate as normal. Whether the clients internal ip is in the header or apart of each request (query param) doesnt really matter, just how can I get the internal ip to the server without disrupting the normal browsing activity of our users?
Please let me know if I have misunderstood your suggestion about the reverse proxy. FWIW we use nginx as a reverse proxy at the datacenter to load balance and handle certain API endpoints.
Thanks,
James
On Sun, Feb 15, 2015 at 4:45 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 16/02/2015 11:46 a.m., Yuri Voinov wrote:
>
>
> 16.02.15 4:40, James Beecham пишет:
>> Hi Yuri,
>
>> Thank you.
>
>> Are these HTTPS CONNECT requests coming over port 80? If not
>> would I need
>
> It depends. In different configurations uses different ports. In
> transparent interception mode your absolutely need separate ports
> for HTTP/HTTPS. In forwarding mode you cah use one port, but with
> SSL parameters.
>
And James, since you are domain admin the question becomes why are you
not running a reverse-proxy "https_port 443" with your domain cert to
receive the HTTPS traffic and forward it to the origin servers?
Amos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBAgAGBQJU4T2TAAoJELJo5wb/XPRjAmAIAK5HfCAwSMUCXIeFNIPzppBG
24i0loL2Bhg9z/J9ec0iENOEO4XV0LPkNQT2UmyRxO4HZis5Su3Hc8R50tG6mrPf
EdU1H+nTUTygGQkm3nK7OmfdbSy/kV6aXmLM4pToYwwV3j15GDlW0wA0DN9JZhIG
WIBfwb+fCcjD5FJq9HWdGajeWgT9yuT54ufqrRJyjnq2LQMW8q7kbxrr6ue9eZxZ
9Fsz1GnoneHO5nQ1BHbp/rTo+GCEfZLO+r87/6tCcYkYmtKsvP6kI7fCCSE1X0N6
bjUj1iya5Ec92PsPc2ubmemTBIL/P572nO15fKesxlSYWCsdkpsbA0bygiksbZI=
=ZEKG
-----END PGP SIGNATURE-----
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
