W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2007

Re: status on partitioned drafts

From: Adrien de Croy <adrien@qbik.com>
Date: Wed, 14 Nov 2007 13:07:00 +1300
Message-ID: <473A3C24.7050007@qbik.com>
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

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.



Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
Received on Wednesday, 14 November 2007 00:06:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:43 UTC