dns problem with browsers only?

Kevin Darcy 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.


- Kevin

beaman wrote:

> Hey,
>
> 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://150.148.80.40), 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 150.148.80.40.
>
> Bill





More information about the bind-users mailing list