Resolving Intranet URLs
On problem with Firefox that enterprises commonly report is that there is no easy way to tell Firefox that http://name is a URL on your intranet. Firefox will go through the normal process of attempting to add www and com to the name and it will fail. I think I've found a solution.
The default prefix and suffix that Firefox uses to "fix up" the URL can be specified. The defaults are "www." for the prefix and ".com" for the suffix.
You can change the prefix with the preference browser.fixup.alternate.prefix and you can change the suffix with the preference browser.fixup.alternate.suffix. So to make this work for your company, change the prefix to an empty string and change the suffix to .yourcompanyname.com. Don't forget the "." at the beginning of your domain.
With that change, typing in http://foo will go to http://foo.yourcompanyname.com.
From what I remember, the change foo -> http://www.foo.com happens only if the DNS is not able to resolve "foo". So simply properly configuring the DNS resolver (e.g. add the correct search statement in /etc/resolv.conf or let your DHCP do it; I don't remember how to do it on Windows) solves the problem as well.
Yep, we routinely use short names like 'intranet' in our office, and expect them to resolve correctly, without any browser-level configuration.
I don't completely understand either, but I know we consistently get reports from enterprises that Firefox treats these intranet URLs different than Internet Explorer.
No idea.
If you press CTRL-ENTER in the URL bar, "www." and ".com" are added before trying to resolve directly; maybe that's what these people are doing?
It's IE that automatically tries http://www.intranet.com when I type "intranet" in my experience. Chrome does this, too. They both slide a message in that asks if you meant http://intranet, at least.
Firefox is the only one that just goes where you tell it to.
There was an RFE for creating a "default domain" string...
Okay, I have time for a longer answer than I thought...
Mike, there was a lot work done in this area, circa 2000 by Network QA and the community.
The URL is supposed to be an FQDN. (I know, don't start yelling, that's what the original RFC's said). But if the hostname field isn't an FQDN isn't, then we certainly never got around to really adapting hostname->DNS lookups. (There is also the topic of PQDNs in URLs, which I completely object to, because it really should have remained a (unix) shell convention. The only place I've seen them in use is Sun Microsystems, which sort of speaks to itself...)
Instead, a lot of what was made was sort of a bad imitation of IE3-6, via NN4. (I wasn't in CPD until the Mozilla project was pretty close to release, so I don't know how the sausage was made, but I tested a lot of the functional behavior and edge cases).
I wouldn't mess with the fixup stuff, unless you read the remaining open bugs. I vaguely remember that some enterprising people in the community did this as a workaround, but it also had some major downsides.
I hope that helps.
(benc@meer.net/benc@netscape.com)