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

Re: protocol support for intercepting proxies

From: Travis Snoozy <ai2097@users.sourceforge.net>
Date: Mon, 18 Jun 2007 18:51:47 -0700
To: Adrien de Croy <adrien@qbik.com>
Cc: Henrik Nordstrom <henrik@henriknordstrom.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20070618185147.6ba9d90c@localhost>

I'm going to try and be terse today. :)

On Tue, 19 Jun 2007 12:48:00 +1200, Adrien de Croy <adrien@qbik.com>
wrote:

> However, proxy auto detect can require some configuration.
> Originally proxy auto-detect worked by doing a DNS lookup for the
> name "WPAD".
<snip>
> then someone at MS decided DHCP would be a better option for
> discovering proxy config, and option 252 was created whereby the DHCP
> client issues a request for option 252 as part of a DHCP_INFORM
> message.
<snip>
See the friendly notice at http://www.wpad.com/ for why this was a
REALLY bad idea. He could be hijacking a whole lotta browsers right
now, if he weren't so nice.

> So, we have some browsers that use DNS (which they can control, but 
> which seems to be being deprecated), and others that rely on their OS 
> platform using a private DHCP option that is not formally specified.
<snip>

http://www.wpad.com/draft-ietf-wrec-wpad-01.txt states that option 252
must be supported by clients. Yeah, yeah; not a formal spec, but if
you use part of it, you're in for the whole nine yards.

> Some client platforms don't provide a mechanism where applications
> (such as a browser) can obtain info from DHCP clients or servers
> (i.e. influence DHCP requests, and access response data).  Most
> notable OS that springs to mind is most if not all versions of
> windows.
<snip>

Ironic, ne?

> So in short, IMHO proxy auto detect is fraught with problems.

Totally agree.

> Proxy operation
> ----------------
> There are zillions of applications out there that use HTTP for
> whatever purpose.  Many of these are cobbled together.  Many do not
[follow the standard] ...
<snip>

Yep. And HTTP is a crummy standard at that. It's huge, it's
self-conflicting & ambiguous, it's hard to implement, and there isn't a
reference implementation.

> Many of these apps are very old, and aren't being maintained, but are 
> still in use and relied on.
> 
> This isn't an argument for changes to the protocol actually since 
> proposed changes would break all these apps.

Yeah, backwards compatibility is a bitch. It's one of the biggest
reasons for the current HTTP mess.


> If we could assume that all HTTP agents could work through a proxy,

We do.

> and do proxy auth,

We don't (it's a MAY level thing).

> we should be looking at a more foolproof mechanism  for proxy auto
> configuration.

Agreed.

(hit my length limit)

-- 
Travis
Received on Tuesday, 19 June 2007 01:54:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:10 GMT