Re: why not WPAD?

Hi Peter

in general, WPAD involves up to 4 different systems.

DHCP
DNS
http server for WPAD.dat URL
client (must be configured to use auto proxy detect)

then there's the Proxy

this is 4 places for failure in the WPAD setup.

We find in practise deploying WPAD to be very problematic for customers. 
  If however they could divert ports via the proxy, there's 1 system to 
enforce and advertise the requirements for connection, and it's the 
proxy.  Therefore the proxy vendor has complete ability to develop and 
deploy all the necessary bits.  Neither is it dependent on client 
config.

Since clients may start their browsing with https, therefore there needs 
to be a way within TLS to advertise this.  So actually I think the 
approach is a very good one, and stands to make life a great deal easier 
for all my customers in any case.

Adrien




------ Original Message ------
From: "Peter Lepeska" <bizzbyster@gmail.com>
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Sent: 16/01/2014 08:09:14
Subject: why not WPAD?

>Salvatore's recent draft on trusted proxies
>(http://www.ietf.org/internet-drafts/draft-loreto-httpbis-trusted-proxy20-00.txt)
>presents one approach for browsers to learn about the presence of
>proxies, even when the browser is first using HTTPS to talk to the
>Internet.
>
>But WPAD already exists for this purpose and all of the browsers
>support it in one form or another -- chrome recently added support for
>WPAD over DHCP as I understand it. I know there are implementation
>problems with WPAD and proxy autoconfig but fundamentally what is
>wrong with the approach of leveraging DHCP and DNS to discover proxies
>and then relying on a simple javascript-based script to determine when
>the proxy should be used?
>
>Is there something fatally flawed about the WPAD/PAC model for dynamic
>proxy detection? If this topic is covered in another thread, please
>send me a link to it.
>
>Thanks,
>
>Peter
>

Received on Wednesday, 15 January 2014 21:40:11 UTC