Closed Bug 17657 Opened 25 years ago Closed 23 years ago

Domain Guessing/Internet Keywords: failure to find intranet host

Categories

(SeaMonkey :: Location Bar, defect, P3)

x86
Windows 95

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: jbeaupre, Assigned: jud)

Details

(Keywords: testcase, verifyme)

While trying to view a page from a local server named disneyland
(http://disneyland/),
the browser misidentified the address as the www.disneyland.com server (which
Mozilla will accept as http://disneyland/ also, same as our server address
).  The problem is due to the full address name not being used.

Note:  This may not be reproducable outside our local network, but similar
errors are likely to occur whenever a local network has a server with the same
name as a popular site and full address names are not used.
Summary: Build 1999103108 accesses wrong server → Build 1999103108 accesses wrong server {Autocomplete}
Tested this on a small LAN with both NetBEUI and TCP/IP active on all boxen.
URLs of the form "http://hostname/" loaded the correct content from the correct
local server, even if that hostname does not appear in the hosts file,
and even if http://www.hostname.com/ exists out on the internet. If there
was no active webserver on that boxen at the time, the load silently failed
(after the host was resolved and a GET was sent), and the autocomplete did
*not* change the URL to something ending in .com.

The following messages appeared in the status bar for all these attempts for
all valid local hostnames:
Resolving hostname
Connecting to hostname

It is possible that the disneyland server on the reporter's LAN was
temporarily not resolvable, that the boxen on that LAN are using a different
protocol set, and/or that the reporter's LAN is using some MS esoterica like
WINS or DHCP that isn't interoperating correctly with Necko. Any of these
could poetntially explain the difference between what I'm seeing and what the
reporter saw.

Tested on Win95 using 1999-10-31-08-M11 binary (same as reporter).

Additional Information:
Confirmed that http://disneyland/ does get transformed to
http://www.disneyland.com - is there any reason this should happen,
as well as "disneyland" getting that transformation? Isn't the latter enough?

There are plenty of machines on intranets with names that can also be found
between www. and .com on the internet, and getting an internet site instead
of the desired intranet site seems like hideous punishment for misremembering,
mistyping, or having the misfortune to try to access while it's rebooting,
a valid intranet server name.
Sorry, here's a little more detail.  Yes, the intranet server is active and
loads with http://disneyland.eesus.jnj.com (this is behind our firewall, sorry
folks).  The network is Novell based, WINS is disabled, but DHCP is listed in
the Novell client settings in the Name Resolution Order after DNS.
Cheap shot:  Isn't "MS esoterica" redundant?
Let me know if I can provide any additional information.
Assignee: leger → gagan
Component: Browser-General → Networking-Core
QA Contact: leger → tever
tever, can you try to reproduce.
Assignee: gagan → valeski
Summary: Build 1999103108 accesses wrong server {Autocomplete} → failure to find intranet host
Target Milestone: M13
Changing summary from: Build 1999103108 accesses wrong server {Autocomplete}
to: failure to find intranet host
Status: NEW → ASSIGNED
can you goto the ip address of the disneyland server directly?
http://disneyland/ gets resolved as disney.go.com, but http://xxx.xxx.xxx.xxx/
is resolved correctly as our intranet server (sorry, someone here might get in a
tangle if I start giving out server IP numbers).  Build ID this time is
1999111520 (M11, I believe).  Have not tried more recent versions.
it's sounding more and more like you somehow enabled keywords. The default is
off though so somehow it was turned on either by file corruption, or on purpose.
To disable it you would change the "keyword.enabled" line in your all.js file to
false.
Bulk move of all Networking-Core (to be deleted component) bugs to new
Networking component.
is this still a problem?
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
I am unable to reproduce this. reopen if we have a test case.
I can not reproduce this either - closing.
Status: RESOLVED → CLOSED
REOPEN:
nothing should be "CLOSED" yet.
Status: CLOSED → REOPENED
Resolution: WORKSFORME → ---
Summary: failure to find intranet host → DNS: failure to find intranet host
RESOLVED/WRM:
This is a testcase. I think this behavior should be changed, but I've handled
that in other bugs.

For this to happen, the "Internet Keywords" preference must be turned off.

The logic becomes:

for "hostname"

1- Lookup "hostname" for resolution. Allow OS to do conversion to fqdn.
2- If it doesn't resolve, send "www.hostname.com". (this is probably done via an
 internal redirect, b/c the URL location changes as well).

For example, on the netscape network:

http://home/ finds http://home.netscape.com.

http://packetgram becomes http://www.packetgram.com/, and then loads the page.

(interestingly http://packetgram. fails, because our DNS code also uses a
trailing "." as a literalizer).

This is now a testcase.
Status: REOPENED → RESOLVED
Closed: 25 years ago23 years ago
Keywords: testcase
QA Contact: tever → benc
Resolution: --- → WORKSFORME
Component: Networking → URL Bar
QA Contact: benc → claudius
Summary: DNS: failure to find intranet host → Domain Guessing/Internet Keywords: failure to find intranet host
Keywords: verifyme
QA Contact: claudius → benc
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.