Closed Bug 122049 Opened 24 years ago Closed 24 years ago

False "www.. could not be found" when address exists!

Categories

(Tech Evangelism Graveyard :: English Other, defect)

Product:
Tech Evangelism Graveyard
Component:
English Other
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: mcchambers, Unassigned)

References

(
URL
)

Details

Whenever I try to go to the above address I keep getting that www.. could not be found. Please check the name and try again. Yet the address exists. Ideas?
DNS mess? Trying to go to http://www.energyfm.ca triggers replies from star94.com And star94.com run a webserver at that DNS/IP. Not to say they don't run more, but ports can be set up wrong: Nalookup: Non-authoritative answer: Name: star94.com Address: 216.251.248.68 Non-authoritative answer: Name: www.energyfm.ca Address: 216.251.248.68 Are any other webclients able to load www.energyfm.ca?
win2k and a 3h old CVS build 216.251.248.68:80 -> 192.168.0.10:4224 [AP] HTTP/1.1 302 Found..Date: Sun, 27 Jan 2002 04:55:40 GMT..Server: Apach e/1.3.19 (Unix)..Location: http:./index.jhtml..Keep-Alive: timeout=15. .Connection: Keep-Alive..Transfer-Encoding: chunked..Content-Type: tex t/html; charset=iso-8859-1....c6 ..<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">.<HTML><HEAD>.<TITLE>302 Found</TITLE>.</HEAD><BODY>.<H 1>Found</H1>.The document has moved <A HREF="http:./index.jhtml">here< /A>.<P>.</BODY></HTML>...0.... They redirect to "http:./index.jhtml" I dunno if this URL is valid -> confirming (works with NS4.7x and IE5)
Assignee: asa → darin
Severity: critical → normal
Status: UNCONFIRMED → NEW
Component: Browser-General → Networking: HTTP
Ever confirmed: true
OS: Windows XP → All
QA Contact: doronr → tever
Hardware: PC → All
hmm well lynx can't load it either, and w3c validator says: 500 Can't connect to :80 (Bad peer address)
Darin (or Andreas) know if this is a valid redirection. If not (i expect this) -> Evangelism Rkaa: You should install NS4.x again and you can see that it works :-)
./ is a relative URl not allowed by the NEW RFCs -> Evanglism
Assignee: darin → momoi
Component: Networking: HTTP → English: Non-US
Product: Browser → Tech Evangelism
QA Contact: tever → jonrubin
Version: other → unspecified
> ./ is a relative URl not allowed by the NEW RFCs Please tell us which RFC disallows it. Also which older RFC allowed it?
see RFC2616 section 14.30: Location = "Location" ":" absoluteURI matti may have been referring to RFC2068, the older HTTP spec.
Thanks, Darin. I checked both HTTP1.0 (RFC 1945) and the obsoleted version of HTTP 1.1 (RFC 2068). In neither of them, relative URI is allowed for Location response header. So we have no backward compatibility issue here. There is no need to support the relative URI for Location response-header. This is an evangelism issue, then. I would like to ask, however, if anyone here knows why NN4 and IE4/5/6 support relative URI. Are they simply being kind and realistic about potential errors in the Location response-header?
Shouldn't the message box also state that it did found it but could not connect?
Netscape 4.74 allows this btw, and we all know what IE does *puke*
WFM, need verification.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Mass reassigning English-Other bugs to general default assignees.
Assignee: momoi → english-other
QA Contact: jonrubin → english-other
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.