Re: why not WPAD?

Adrien,

That makes sense to me -- it's overly complex to deploy and therefore
prone to failure. As far as needing the client to be configured to use
proxy auto detect, that might also be the case for the TLS-based proxy
detection scheme. Also, the TLS-based scheme requires an in-path
proxy, which sounds like its not an issue for your customers. And it's
also not an issue for mine, though I think the ability to deploy out
of path opens up some interesting possibilities. I wonder if you'd
feel the same way about WPAD if implementors had fully committed to it
-- if browsers implemented the spec consistently with auto proxy
detect enabled most of the time. Inconsistent implementation due to
lack of commitment might also turn out to be a problem with the
TLS-based scheme.

I'm still not sure that WPAD is fundamentally worse. And plus it already exists.

Peter

On Wed, Jan 15, 2014 at 4:39 PM, Adrien de Croy <adrien@qbik.com> wrote:
>
> 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 23:39:41 UTC