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 an
embedded http server in the proxy is a de facto requirement to communicate
with web clients, since there is no web client <-> proxy signalling layer
in http/1

> Another issue  with WPAD compared to a per-connection
> intercept/enforcement scheme is that it's one-off.  The client performs
> 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. Some
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 to
> 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 the
> 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. With
pacfile you can tell web client "here are internal websites, you can reach
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 proxy
node will degrade availability and scalability.

(and sometimes a different proxy gateway sits before a private
non-internet link with a partner)

Regards,

-- 
Nicolas Mailhot

Received on Thursday, 16 January 2014 10:09:54 UTC