- From: Adrien de Croy <adrien@qbik.com>
- Date: Wed, 14 Nov 2007 13:07:00 +1300
- To: HTTP Working Group <ietf-http-wg@w3.org>
I know it shows issue I5 (Via is a MUST) as closed, but this requirement sets off many warning bells for me. I've totally lost count of the number of times a customer has asked whether there's any way they can ensure their ISP can't see they are running a proxy server. Regardless of what any of us feels about the ethics of ISPs blocking shared access, the customers are expressing a clear requirement. For these customers, mandatory insertion of a Via header would be highly problematic, advertising the fact they are using a proxy. There are other sorts of proxies as well (such as those commonly used for satellite access), where users connect through a proxy on localhost, possibly a split proxy. I guess it's not such an issue for these. An intercepting proxy that wishes to maintain transparency can't be inserting or modifying any headers at all though. So, I see several reasons why the Via header is problematic - the main one being customer requirements. I can only really see one reason why it could be useful, e.g. to try and debug issues / track down potential problems. Am I missing a bunch of use-cases for the Via header? Is it expected to be used by upstream caches or servers? At the moment I'm still strongly inclined to not put it in, or make the default setting not to put it in. It's hard enough getting users to do simple things, trying to explain the ramifications of a header like Via is a job I'd rather not take on. Putting a Via header in for responses is fine though, just the request side is where I see the major problem. Regards Adrien -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
Received on Wednesday, 14 November 2007 00:06:27 UTC