dns problem with browsers only?
kcd at daimlerchrysler.com
Thu Nov 11 00:55:10 UTC 1999
It's just a crappy webserver that unceremoniously closes the HTTP connection
whenever it doesn't recognize the Host: header on an HTTP request. Your
resolver, presumably with the help of a default domain or a searchlist, helped
you get *to* the webserver, but then, because of the name you used to access
it, the webserver's user-unfriendliness prevented it from sending you back
anything meaningful, not even a proper error response. This behavior probably
violates the HTTP RFC (but I'm too lazy to look that up right now).
Have I seen this *particular* bogosity before? Not that I can recall. Have
I *generally* seen shoddy behavior like this from mainframe-based web
servers? You betcha.
> Has anyone seen this before? pc's can use short name for telnet, ping, and
> nslookup. But when they use a short name in a browser (http://intranet),
> it doesn't. The web page is not displayed and they get a 500 error. But
> when they use the FQDN (http://vm.cfsan.fda.gov) or the ip address
> (http://126.96.36.199), bingo - it works! We have tried going to different
> web servers (http://intranet, http://updates) and using different browsers
> (netscape, hotjava, ie), but we get the same behavior. nslookup looks fine
> for nslookup vm and nslookup 188.8.131.52.
More information about the bind-users