Closed
Bug 3126
Opened 26 years ago
Closed 26 years ago
DNS: incredibly long fqdns fail
Categories
(Core :: Networking, defect, P2)
Core
Networking
Tracking
()
VERIFIED
FIXED
M10
People
(Reporter: umesh, Assigned: gordon)
Details
(Keywords: testcase)
(This bug imported from BugSplat, Netscape's internal bugsystem. It
was known there as bug #324623
http://scopus.netscape.com/bugsplat/show_bug.cgi?id=324623
Imported into Bugzilla on 02/11/99 19:35)
Created by Victor Riley (var@sgi.com) on Friday, September 18, 1998 2:03:16 PM
PDT
Additional Details :
Tested on Netscape 4.05, 4.06, 4.5b1, all IRIX.
nslookup result:
nslookup
www.llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch.co.uk.
sgi
Server: fddi-sgi.SGI.COM
Address: 192.26.80.37
Name:
www.llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch.co.uk
Address: 194.159.85.168
But just try going there with netscape 4.05, 4.06,
or 4.5b1. It always complains that there isn't a
valid DNS entry for it. Using the IP address
works...
Then of course, there's the somewhat sillier, but
still legitimate, and a bug in netscape:
http://twas.brillig.and.the.slithy.toves.did.gyre.and.gimble.in.the.wabe.all.mimsy.were.the.borogoves.and.the.mome.raths.outgrabe.jabberwocky.com/
Which also has the CNAME of just plain
jabberwocky.com, and that (jabberwocky.com) works.
Verified this and the name is chopped off when
sent to the proxy server.
Netscape Proxy is unable to locate the server:
twas.brillig.and.the.slithy.toves.did.gyre.and.gimble.in.the.wab
The
server does not have a DNS entry. Check the
server name in the
Location (URL) and try again.
Comment 1•26 years ago
|
||
reassinging PSE to rvelasco
Comment 2•26 years ago
|
||
Chris said Spence should have this! Go spence!
Updated•26 years ago
|
Assignee: mcafee → spence
Updated•26 years ago
|
Assignee: spence → gagan
Comment 3•26 years ago
|
||
i believe gagan has been dealing with 4.0x stuff. correct me
if i'm wrong ...
Comment 4•26 years ago
|
||
setting paulmac as QA contact for all gagan's bugs (sorry for the spam)
Updated•26 years ago
|
Target Milestone: M6
Per DP's suggestion marking these till M8. Though Necko lands with M7, we will
be able to verify it for M8.
Comment 6•26 years ago
|
||
I'm moving this to target M9, Necko will be enabled somewhere during late M8 or
early M9. We will need to get on this and it cannot be postponed past the M9
milestone.
Changing all Networking Library/Browser bugs to Networking-Core component for
Browser.
Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do
this in a bulk change. If this happens, I will fix. ;-)
Assignee: gagan → gordon
Status: ASSIGNED → NEW
Summary: Communicator DNS lookup can't handle long names → NECKO: Communicator DNS lookup can't handle long names
Target Milestone: M9 → M10
Gordon: this may still be a problem in Necko. When we land DNS pl. check this.
Updated•26 years ago
|
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Updated•26 years ago
|
Status: RESOLVED → VERIFIED
Comment 9•26 years ago
|
||
these names actually work on all platforms, go necko!!!!
Comment 10•25 years ago
|
||
Bulk move of all Networking-Core (to be deleted component) bugs to new
Networking component.
Comment 11•24 years ago
|
||
FQDNs can contain up to something like 63 characters per label and 252
characters per fqdn.
I'll be writing at generic test case for fqdns and posting it on www.packetgram.com
Comment 12•24 years ago
|
||
+testcase
I've added a DNS basic/smoketest for long names. We are currently only testing
for valid fqdns. I'll be writing a specification-level document eventually too.
+plats/OS =all
Keywords: testcase
OS: IRIX → All
Hardware: SGI → All
Summary: NECKO: Communicator DNS lookup can't handle long names → DNS: incredibly long fqdns fail
You need to log in
before you can comment on or make changes to this bug.
Description
•