127396 - Proxy: "no proxy" cannot block hostnames w/ default domain

Status: VERIFIED DUPLICATE of bug 91587

(Core :: Networking, defect)

Description

[Spiros Ioannou]

See also bug http://bugzilla.mozilla.org/show_bug.cgi?id=76945 for linux.
I didn't reopen this bug since this DNS issue is resolver/OS-specific.

Win2k, Gecko/20020220
Mozilla should resolve hostnames indipendently from the existence of a proxy.
When using relative hostnames, those are not first rewritten as fqdns before 
1) been passed to the proxy server, resulting in "Host not found" response from 
   proxy
2) been checked against the "No proxy for" setting.

So if my domain is ".image.ntua.gr" , my proxy is "proxy.ntua.gr:8080" and i
write www at the url, mozilla displays www.ntua.gr instead of www.image.ntua.gr.
This is true even if I have "No proxy for .gr". The correct behaviour is
observed only when removing the proxy.
And yes, it's not the DNS server that appends the correct domain when working
without a proxy, it's the win2k resolver, so I believe this should be rather
easy to fix(?)

Comment 1

[benc]

Well, the behavior here is more complicated that what you think, so I'll try to
explain everything to you before finding a dupe or resolution.

When you type a hostname, and you have a proxy selected, the hostname is sent to
the proxy. 

If you want no proxy to catch the hostname, (by expanding to an FQDN before
doing the no proxy check, there is a bug on that.)

Otherwise, what happens is left to the proxy server, possibly the server sends a
3xx redirect (which would cause the URL to change...)

Comment 2

[Spiros Ioannou]

Yes I know that when using the proxy you send the whole url in the GET, but the
only reason I can see to avoid making the mentioned change is when the computer
where the browser runs doesn't have a resolver (if for example it is behind a
firewall or if a DNS server has not been configured). In this case the resolving
should be left to the proxy alone, but in other cases I believe that the local
resolver is more preferable because of the custom DNS search order specified by
the user. I can't see any protocol violation with this, why not making it an option?

Comment 3

[benc]

There is no reason why sending GET FQDN to a proxy is worse than GET HOSTNAME.

Nobody runs w/o a resolver anymore. Some people run in an environment where the
availability of DNS is limited.

In fact, I don't know if we truly support DNS-less environments.

The point is, basically non-FQDN's are bad, this is another example of that.

While, I'm at it, -> NEW, b/c I see this some proxy logs from an old test.

Comment 4

[benc]

nsbeta - nominating any DNS bugs that involve abmiguity or increasing the
likelihood of being externally maniuplated (via DHCP or network changes).

Comment 5

[Calvin Liu]

*** Bug 143643 has been marked as a duplicate of this bug. ***

Comment 6

[Spiros Ioannou]

I find the previous summary more appropriate, the problem doesn't concern only
the "no proxy for" configuration, normal operation is affected also: 
When issuing a non-fqdns on the URL bar, the site contacted depends from the
existence or not of a proxy. So the user gets a different site if he enables or
disables the proxy. Why? because when issuing "www", the proxy resolves this
using his DNS search order, which may be (and usualy is) different from the
client's DNS search order. The question is if we want to support non-fqdns on
the url; I strongly believe that this should be supported because:
a) it is already supported when not using a proxy
b) it should be supported because that's why the resolver on every OS has a
search order
c) it is supported on every other internet service (ftp,telnet et.c) and so it
is natural to assume that www expands to www.mydomain and not to www.proxy's_domain

Comment 7

[benc]

I realize what is going on here. You are actually asking for two things:

1- Client DNS resolution of HTTP proxy requests.

2- Better proxy of requests that have just hostnames.

These are two pretty distinct problems, I think maybe you think they are related
because you think that name resolution includes adding the default domain to the
hostname before making the no proxy decision.

Comment 8

[benc]

#1 is best covered in bug 150580, if that guy would just make up his mind and
not change the meaning of the bug again.

Comment 9

[Doug Turner (:dougt)]

darin can you look at this.

Comment 10

[Darin Fisher]

sounds like a duplicate to me.

*** This bug has been marked as a duplicate of 91587 ***

Comment 11

[benc]

VERIFIED. Read that bug, file new bugs if we missed something in an open bug.