190324 - Domain Guessing trumps "No Proxy" of hostnames

Status: RESOLVED WONTFIX

(Core :: Networking, defect)

Description

[benc]

While working on invalidating bug 154798, I noticed the following that I had not
noticed before:

No proxy does a string match on the suffix of the URL hostname, before I had
thought it might do a simple string match anywhere.

This means that, although you cannot do block single hostnames (w/o an fqdn) by
putting in the default domain of your system into "No proxy", you can block
individual hostnames by simply putting the hostname into "No proxy".

One problem with this setup is that if you have some kind of connection failure,
Domain Guessing (and probably Internet Keywords as well) will pickup on the
failure, and redirect Necko to attempt to connect to http://www.hostname.com.
Since "no proxy" will not catch hostname on a suffix match, this will most
likely go out to the proxy.

Besides the usual level of badness associated with Domain Guessing, this is
additonally too clever, because if a user put a hostname into "no proxy", you
would assume that they are inherently declaring that they expect the host to be
on and available on the local network. If this connection were to fail, that
should be the end of the chain of events. How is asking a proxy for help going
to matter when I already said it is here?!

Realistically, I don't think this is worth fixing, because we would have to
create a no-proxy flag that gets sent to docshell to supress domain guessing if
it matched no-proxy. That is too much thinking for something that just needs to
be turned off.

This analysis, however, might help explain some really weird behaviors in dupes
of bug 91587.

Comment 1

[Doug Turner (:dougt)]

--> darin

Comment 2

[Darin Fisher]

-> default owner