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

Re: protocol support for intercepting proxies

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Tue, 19 Jun 2007 01:04:11 +0200
To: Travis Snoozy <ai2097@users.sourceforge.net>
Cc: Adrien de Croy <adrien@qbik.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <1182207851.26585.10.camel@henriknordstrom.net>
sön 2007-06-17 klockan 19:29 -0700 skrev Travis Snoozy:

> My biggest issue with using existing proxy auto-detection is that WPAD
> is just an I-D; there is no standard. Implementation-wise, it's
> de-facto a standard

Yes, on all the above..

>  -- but I can't comment on the interoperability of
> the implementations.

From my experience it's fairly OK provided the admin sets up both DHCP
and DNS properly. Which is not by any means hard to do. The instructions
needed for the average network admin fits on a single page. 

The main problem with WPAD is it's assumption that the client is a full
fledged browser capable of running JavaScript. There is also a need for
something simpler where the client can discover what proxy to use, not
to discover the location of a program/script which it can run to
calculate what proxy to use.

> So, yeah, the problem needs to be solved, but
> browsers technically don't have a standard way of doing it. That said,
> any solution that _does_ come up is likely going to be DHCP and/or DNS
> based, and locked to the local network (a la zeroconf DNS Service
> Discovery).

I certainly would not mind having a HTTP response code where an
interception device could tell the client that "sorry, you need to use a
proxy in this network" asking the client to perform automatic proxy
discovery even if normally not enabled. But having that same message on
the intercepted connection tell the client which proxy to use is
absolutely wrong.


Received on Monday, 18 June 2007 23:04:22 UTC

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