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(?)

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...)

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?

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.

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

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

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

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.

#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.

darin can you look at this.

sounds like a duplicate to me. *** This bug has been marked as a duplicate of 91587 ***

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