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

Re: Some proxy needs

From: Eliot Lear <lear@cisco.com>
Date: Mon, 09 Apr 2012 17:55:03 +0200
Message-ID: <4F830657.4010900@cisco.com>
To: "Adrien W. de Croy" <adrien@qbik.com>
CC: Poul-Henning Kamp <phk@phk.freebsd.dk>, Nicolas Mailhot <nicolas.mailhot@laposte.net>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>


On 4/8/12 2:50 PM, Adrien W. de Croy wrote:
> [discoverability]
>>
>> I would have thought this was a job for DHCP ?
>>
>
> DHCP has some issues with this, it's not standardised, and option 252
> vs DNS lookups for WPAD... it's a bit of a mess.
>  
> and has no capability for communicating policy, or requirements for
> enforcement.
>

DHCP's problems aren't really that.  It's easy to write a new option. 
DHCP's problems are the following:

 1. Will O/S vendors adopt a new option?
 2. Will browsers tie to the O/S for the information (it's inherently an
    O/S function and you wouldn't want http clients making DHCP calls on
    their own)?

Let's assume for a moment that a PAC file or something similar is
pointed to.  That's probably rich enough for most.  Assuming the file is
shared over SSL, then there's the matter of whether the source is
trusted.  That's ALSO not a DHCP problem, but a problem with ANY
discovery mechanism.

I'll argue that if you can get O/S vendors into the game, then [2]
should follow because it probably doesn't make sense to have more than
one of these things on a host, and could lead to unintended inconsistent
behavior.

Eliot
Received on Monday, 9 April 2012 15:55:33 GMT

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