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.

Helping folks customize and deploy Firefox is what we do. For more information, contact Kaply Consulting.

Please note: I reserve the right to delete comments that are offensive or off-topic.

Leave a Reply

Your email address will not be published. Required fields are marked *

8 thoughts on “Resolving Intranet URLs

  1. 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?

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

  3. Not sure if it’s a new option or not in Firefox, but you can change this via the parameter: browser.fixup.dns_first_for_single_words by setting it the value = true.
    When you type in “intranet” in the search barnow, then it will go to “http://intranet” as expected.
    previously it would try to search for intranet as if it were a webpage due to the prefix/suffix options.