On Fri, 2003-02-14 at 22:27, Jon Biddell wrote: > >But don't use interception for accessing > > the proxy. (incorrectly called transparent proxing). > > Rob, I'd be interested in your reasoning behind this - I thought > "transparent proxying" was widely used (I know Bidpond here use it).
Sure. Interception of TCP streams breaks the end to end semantics of TCP. This raises issues - 1) Trust. The web browser can no longer trust the results it recieves. 2) Accuracy. Because the web browser doesn't expect any alteration, it won't send proxy control headers (such as cache-control). 3) Reliability. If the proxy farm is down, the client cannot 'fall-back' to a direct link, because it was *already* on a direct link. ISP's have a quandry with interception caching: * it can cause problems. * without it, it's a lot less economical being an ISP. (Users may not configure their software to use the cache, and the support costs if you make it mandatory via the scheme in my previous email are horrendous for an ISP - "Why do I have to do X, why aren't you like every other ISP") There are tools (layer 4 and 7 switches, for instance) to address the reliability issue, but the trust and accuracy ones cannot be fully addressed. In summary, I understand why ISP's perform transparent caching, even though the result is that extensions to (and implementation of obscure features in) HTTP become harder to roll out and test (because they may fail to pass through the intercepting caches). Organisations don't have the excuse of ISP's - they are able to set a policy and expect users to implement it, and they can setup autoconfiguration (such as wpad) to make the cost of administration very low. Rob -- GPG key available at: <http://users.bigpond.net.au/robertc/keys.txt>.
signature.asc
Description: This is a digitally signed message part
