W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

Re: why not WPAD?

From: Adrien de Croy <adrien@qbik.com>
Date: Thu, 16 Jan 2014 11:31:31 +0000
To: "Nicolas Mailhot" <nicolas.mailhot@laposte.net>
Cc: "Peter Lepeska" <bizzbyster@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-Id: <emf0a5839d-eca5-4524-be28-65b72517400f@bodybag>

------ Original Message ------
From: "Nicolas Mailhot" <nicolas.mailhot@laposte.net>
To: "Adrien de Croy" <adrien@qbik.com>
Cc: "Peter Lepeska" <bizzbyster@gmail.com>; "ietf-http-wg@w3.org" 
Sent: 16/01/2014 23:09:22
Subject: Re: why not WPAD?

>Le Jeu 16 janvier 2014 00:59, Adrien de Croy a écrit :
>>  Hi Peter
>>  actually IME the client config is the smallest problem. Usually it's
>>  the DHCP, DNS or WPAD.dat http server.
>The DNS and DHCP parts are big problems. The http one is not. Right now 
>embedded http server in the proxy is a de facto requirement to 
>with web clients, since there is no web client <-> proxy signalling 
>in http/1
>>  Another issue with WPAD compared to a per-connection
>>  intercept/enforcement scheme is that it's one-off. The client 
>>  WPAD discovery at the start, and has a static config. After that, it
>>  won't alter behaviour
>That's a huge problem you can't notify clients a proxy went down before
>they restart. Some users like to keep browsers open ad vitam eternam. 
>browsers keep stuck on the dns resolution as it happened during the
>pacfile read, even if the dns of some web sites has changed since.
>>  If OTOH you are doing something per-connection, you have the ability 
>>  alter/tailor behaviour. For example don't bug the client for certain
>>  destination IPs, or source IPs, time of day etc. etc. And this has 
>>  opportunity to greatly reduce the number of systems involved and
>>  opportunity for errors.
>That does not work so well if only part of the traffic is proxified. 
>pacfile you can tell web client "here are internal websites, you can 
>them directly, don't bother with me" and in big corporations internal
>accesses are the bulk of the traffic, forcing it to a per-connexion 
>node will degrade availability and scalability.

What I meant was really the opportunity to do something each connection 
rather than necessarily doing it.

After the client knows it must use a proxy, it will not be directly 
connecting via the router that was issuing this challenge.  Normally 
also intranet traffic need not go via this either so you avoid proxying 

So I guess you have the same failover issues as WPAD.  But you wouldn't 
want to add another few RTs plus proxy estabilshment for each 


>(and sometimes a different proxy gateway sits before a private
>non-internet link with a partner)
>Nicolas Mailhot
Received on Thursday, 16 January 2014 11:32:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:23 UTC