varnish with ssl
schmidt at ze.tum.de
Tue Apr 13 14:04:06 CEST 2010
Ken Brownfield wrote:
> This is far-ranging problem that isn't unique to Varnish or SSL. What is typical of CDNs, load-balancers, and proxies of all sorts is to set a header with the IP of the request *it* received. That header is then passed down and can be parsed by your upstream. X-Forwarded-For is the standard header for this, but the format and naming of this header can vary (no pun intended).
> You can imagine how fun it is to handle IPs for a client request that goes through a CDN's proxy/cache network, through your load-balancer, then Varnish, then the upstream web server:
> Client = 18.104.22.168
> CDN = 22.214.171.124
> sets => CDN-Client-IP: 126.96.36.199
> LB (e.g., Pound) = 188.8.131.52
> sets => LB-Client-IP: 184.108.40.206
> Varnish = 220.127.116.11
> sets => X-Forwarded-For: 18.104.22.168
> Your upstream receives the request from 22.214.171.124 with the following headers:
> CDN-Client-IP: 126.96.36.199
> LB-Client-IP: 188.8.131.52
> X-Forwarded-For: 184.108.40.206
> You'll care about the highest level one (CDN-Client-IP in this case), something like:
> IP = CDN-Client-IP or LB-Client-IP or X-Forwarded-For or <TCP connect IP>
> Hope it helps,
At Least it would be consistent for both if varnish able to handle both and not
have to go through another system. KISS apply's here too. Every new program adds
new Bugs, new security holes and increases the maintenance work.
Squid does handle https: request and so do all the other reverse proxies I know.
Would make replacing squid with varnish a lot less painful.
I don't see the license problem. It should be optional. Use it when is OpenSSL
is there, leave it if not.
Gerhard Schmidt | E-Mail: schmidt at ze.tum.de
WWW & Online Services |
Tel: 089/289-25270 |
Fax: 089/289-25257 | PGP-Publickey auf Anfrage
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 543 bytes
Desc: OpenPGP digital signature
More information about the varnish-misc