Nathan Ward wrote:
Simon Lyall wrote:
It breaks a few places that use the IP address to auth http sessions, apparently some sites don't believe these weird cookie thingies are ready for prime time.
Hmm. This would be a problem if your requests for the same site were going to different proxy servers. I don't think that happens with Foundys, by default. If it does, it's easily 'fix'-able.
We had an issue at Maxnet that was a site which broke in this manner. Essentially they 'authenticated' the customer off the IP address of the proxy, which using WCCP was reasonably static unless a proxy failed. However, after the initial authentication, it then redirected them to an SSL site on 443/tcp, which obviously was not going through the transparent cache farm, and the customer was (correctly) not configured to use a cache. So the request suddenly came from the customer's IP address. Result: The site would refuse to allow them in. A stupid way of doing it, and we solved the problem by excluding the site from the cache. For the life of me, I can't remember what it was, but I recall the site was black and popular. I think it might have been some games thing.
There were a couple of others too, Windows update was one I think.
Really? I've done semi-transparently proxying a number of times before, and had no issues with windows update..
I've seen no issues with WU either with intercept caching. I _have_ however seen issues with the MSN Gaming Zone when the caches hold old download packages because the file name stays the same and for some stupid reason IIS servers don't always seem to respond properly to If-Modified-Since requests, so the caches happily serve stale data. We had other issues like Simon said earlier, with Universities and High Schools requiring access to certain database sites that did it based on IP address. Oh, and people that don't check the X-Forwarded-For: header and use it need to be shot. (Hi Hotmail!) aj (and if the formatting of this email looks dumb, I blame my webmail client.)