Making Browsers Honor the DNS SearchDomain?

Craig A. Smith asks: "I've always been able to use simply 'http://www' to get to my company's web site, presumably because my default search domain was 'mycompany.com.' Suddenly my browser started taking me to 'www.www.com' instead. This happened simultaneously in all browsers (tested Mozilla, IE, NS4.7 and NS7.0) an two platforms (RedHat7.2 and Win2k). The odd thing is the command 'nslookup www' (or dig or host) behaves as desired and still resolves to www.mycompany.com so I don't think this is a DNS issue. I've tried various /etc/resolv.conf settings with no luck ('domain mycompany.com' and 'search mycompany.com'). How do I get my browser to apply the default domain before tacking on the www prefix and .com suffix?"

Comments

Try Opera and disable server name completion?

[Troodon]

Sitting currently before Opera 6.05 on win2k:
Preferences>Network>Server Name Completion>Uncheck 'Try name completion using'
Problem solved, though perhaps not as elegant as getting your current browsers to behave.

quick fix...

[OneFix]

Add it to your hosts file.../etc/hosts for Linux and your default Windoze directory for that other OS...

Another advantage of using this method is being able to use other abreviations for frequently visited sites...

DCHP & Other Things

[wdr1]

Are you using DHCP in Windows? That's the only thing I can think of that would cause all the applications to change at once.

Linux side, I believe if you have 'domain' configured properly in /etc/resolve.conf you should be good to go. You mentioned nslookup works correctly, but does 'telnet www 80' take you to your originial site as well?

A few other things:

- Consider using keywords instead of relying upon DNS to do magic for you. Create a bookmark w/ your company's website & give it the keyword 'www'. That should fix you up. (Keywords are the most currently underrated feature in the browser. Especially in regards to their ability to do searches.)

- You want to consider the above not only for convience, but also so your companies tracking doesn't get screwed up a little. When you hit the site with just 'www' (instead of 'www.foo.com') you drop your cookies. Most sites use cookies at least to track unique visitors if nothing else, and you're probably causing a minor bit of unintended cookie churn.

- Another poster mentioned how browsers require neither 'http://', nor the trailing slash (e.g. on http://www.slashdot.org/). Defaulting to http probably isn't that bad. Especially inside a web browser. After all, it's highly unlikely the user intended gopher://. There is a difference on the trailing slash & it's better to include. If you try to hit a server w/o the trailing slash, you'll simply get a redirect from the server to the version *with* a slash. On broadband, it's totally trival, but for narrowband users, it is noticable. Something to worth keeping in mind for the URLs your link to.

-Bill

Re:DCHP & Other Things

[pne]

There is a difference on the trailing slash & it's better to include. If you try to hit a server w/o the trailing slash, you'll simply get a redirect from the server to the version *with* a slash. On broadband, it's totally trival, but for narrowband users, it is noticable. Something to worth keeping in mind for the URLs your link to.

That's not how I understand it -- after all, there isn't any possible path to request for an URL such as http://www.example.com other than "/". *fx: looks up RFC* Ah, there it is, from RFC 2616 "HTTP/1.1":

3.2.2 http URL

The "http" scheme is used to locate network resources via the HTTP protocol. This section defines the scheme-specific syntax and semantics for http URLs.

http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

If the port is empty or not given, port 80 is assumed. The semantics are that the identified resource is located at the server listening for TCP connections on that port of that host, and the Request-URI for the resource is abs_path (section 5.1.2). The use of IP addresses in URLs SHOULD be avoided whenever possible (see RFC 1900 [24]). If the abs_path is not present in the URL, it MUST be given as "/" when used as a Request-URI for a resource (section 5.1.2). If a proxy receives a host name which is not a fully qualified domain name, it MAY add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy MUST NOT change the host name.

(Emphasis added)

You were probably thinking of paths such as http://www.example.com/some/path , which (if they are directories) typically get turned into redirects to http://www.example.com/some/path/ . But a bare http://www.example.com is legal and equivalent to http://www.example.com/ ; the HTTP request in either case should be "GET / HTTP/1.1" by my reading of the spec.

nslookup is a poor test

[Damien Neil]

nslookup does not use the system resolver library (gethostbyname and friends). As such, nslookup results won't tell you anything about how the system resolver is behaving.

Check what host "ping www" resolves for a better idea of what the system resolver is up to.

- Damien

IE does still require http:// at times

[barzok]

I've found that if you're using a site on anything but port 80, IE will choke trying to find it unless you prefix the URL with http://.

How to do it:

[GoRK]

Here's the way to make pretty much any browser honor your search domain. This works in IE, Moz(win/linux), Opera (win/linux), Netscape:

Type as: http://www/

You can also try just typing www/ .. I seem to remember that that works in some of them.

Also if you disable name completion which I know you can do in Opera (not sure about the others) then just plain www will work.

Enjoy,

~GoRK

Disable smart browsing features

[photon317]

Your browser will probably go back to normal if look for and disable any features called "auto search", or "smart [browsing/urls/etc]". As a side note, one of the really annoying things about Netscape on Unix (at least the old 4.x versions), is that they actually read /etc/resolv.conf themselves, and query DNS servers themselves, instead of using the system's resolver library. You resolver might very well be configured to use some other source first, such as NIS+, but Netscape will have none of it.

My thought too

[0x0d0a]

Be an *exact* explanation of the problem.

If they're using squid, they can recompile and tell it to not use the internal resolver...otherwise, it'll ignore searchdomains.

Re:Finally, somebody who has a clue

[pauljlucas]

The submitter didn't change his search prefix. He even stated that nslookup works correctly. That being the case, it's not a DNS issue. It's the browser that is at fault.

Nitwit.