Closed Bug 154195 Opened 22 years ago Closed 22 years ago

meta refresh URL interpreted different than in NS and IE

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: bugzilla.mozilla.org, Assigned: jag+mozilla)

References

(
URL
)

Details

Mozilla build 2002060216

Sample page returns:
 <META HTTP-EQUIV="Refresh" CONTENT="0;URL=http:/ofx/default.asp">

Netscape 4 interprets this as http://www.ofx.net/ofx/default.asp,
Mozilla as http://ofx/default.asp .

I think "http:/" is not the same as "http://"
you shouldn't encode urls with non-fully qualified domain names in the document.
 you are just lucky that some browsers choose to fixup such urls.  mozilla only
chooses to try www.ofx.com... it doesn't bother with www.ofx.net as 4.x
apparently does, and i'm not convinced that we should.

-> evang
Assignee: darin → doron
Component: Networking: HTTP → US General
Product: Browser → Tech Evangelism
QA Contact: tever → zach
Version: other → unspecified
This is another variation of the deprecated relative url stuff. It is supported
by 4.x but not by mozilla. This has nothing to do with the fixup code that trys
www. and .com. See bug 32966 for more details. Feel free to hand to evangelism
or mark has dup.
andreas: that doesn't explain the error message.  it says "ofx could not be
found. Please check the name and try again."  that means, we parsed the URL as
the author (i.e., we determined that the hostname is "ofx"). so, i don't think
this could be a relative URL parsing issue.
The base url is http://www.ofx.net/ 

With 4.x this is resolved with http:/ofx/default.asp as
http://www.ofx.net/ofx/default.asp taking the host from the base url and the
path from the relative url.

With mozilla we do not recognize the non-base url as relative (in conformance
with RFC 2396!) and interpret it as a malformed absolute url, taking ofx from
the path as host. Prefixing with www. and postfixing with .com does not happen
on links, so we search for ofx as host.

Hope this makes it clearer. 
This seems to be indeed the same as bug 32966.

Andreas, I don't agree with you regarding your interpretation of RFC2396.
"http:/ofx/default.asp" is an *absolute* URI and not a relative one! It is an
absolute URI with an absolute path:

RFC2396 says:
   absoluteURI   = scheme ":" ( hier_part | opaque_part )
   hier_part     = ( net_path | abs_path ) [ "?" query ]
   net_path      = "//" authority [ abs_path ]
   abs_path      = "/"  path_segments

So it is clear that in "http:/ofx/default.asp", "http" is the scheme and
"/ofx/default.asp" is the absolute path and the whole thing is a absolute URI.
And since the scheme part is present, it is of course not a relative URI as
described in section 5 of RFC2396.
This is the relevant part of RFC 2396 (5.2 3)):

      Due to a loophole in prior specifications [RFC1630], some parsers
      allow the scheme name to be present in a relative URI if it is the
      same as the base URI scheme.  Unfortunately, this can conflict
      with the correct parsing of non-hierarchical URI.  For backwards
      compatibility, an implementation may work around such references
      by removing the scheme if it matches that of the base URI and the
      scheme is known to always use the <hier_part> syntax.  The parser
      can then continue with the steps below for the remainder of the
      reference components.  Validating parsers should mark such a
      misformed relative reference as an error.

Mozilla does not implement this backwards compatibility.
We have a patch to fix this (attached to another bug), and I really think we
should be doing so. Its a compatability thing, plus it is part of hte standard,
even if its deprecated.
Applying the patch is within limits of RFC2396, but there has been a
considerable evangelism effort to fix pages that use these kind of relative
urls. So I think without acknowledgement from evangelism and necko-managament
(Gagan) nothing should happen.  
confirming ...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: meta refresh URL interpreted wrong → www.ofx.net should not use relative http: urls anywhere, including META REFRESHes
Summary: www.ofx.net should not use relative http: urls anywhere, including META REFRESHes → meta refresh URL interpreted wrong
this bug is in the envangelism product. as such it is supposed to have a 
summary that fits the evangelism product's standards. the first thing is the 
offending site, and beyond that should be details to help the evangelism team 
evangelize the site. Please don't undo my summary change.
Summary: meta refresh URL interpreted wrong → www.ofx.net should not use relative http: urls anywhere, including META REFRESHes
I entered this bug and I want that other people finding the same problem in the
net can find this bug in bugzilla so they don't enter it again.
Summary: www.ofx.net should not use relative http: urls anywhere, including META REFRESHes → meta refresh URL interpreted different than in NS and IE
As of RFC2396, "http:/ofx/default.asp" is a *absolute* URI with and *absolute* path.
The *host* is missing.

If the host of a http URI is missing, mozilla should insert the host of the
parent object, that is the host of the page containing this reference.

Example: page http://www.test.com/index.html contains the image <img
src="http:/images/test.gif"> and there is no host in the image location, then
mozilla should assume the host www.test.com.
Component: US General → Browser-General
Product: Tech Evangelism → Browser
Version: unspecified → other
The bug is not that others people html is bad. 

The bug is that if there is no host in a http URL, mozilla simply takes the
first path element and treats it as the hostname! This is definitly wrong and
not defined in any RFC.

For an URL like http:/images/test.gif, mozilla complains that it does not find
the host "images"! This is silly.

If there is no host in the http URL, mozilla has to give either a warning/error
or to guess the host.
The reason we load any url at all is because last-ditch url fixup stuff.

This is, as you said, an *absolute* URI. Absolute implies not relative. Taking
the current document's domain would mean that this is a *relative* uri.

But I _still_ think we should fix the backwards compat stuff.
Bradly is right, if it is an absolute URI as you insist (which is by the way
wrong, the intention of the designer of the website is to make this a relative
url) what we do is correct as we try to fix it. An absolute url can not have a
parent or something like that. Then it would be relative by definition. The fix
we try is the only one possible for an absolute URI. We try to guess the host,
we assume the pageauthor forgot a slash. 

The reason this is interpreted differently *is* because IE and NS4.x treat it as
a relative URL and we do not because we do not implement that backwards
compatibility.

This is a tech evangelism bug, if you insist it is not, with your reasoning I
would say it is INVALID.

Guess the host or give an error message.
If you guess the host, take the host from the context you are in.
But do not simply take the first element of the directory as the host just to
have something. 
We guess the host but we can't take it from the context because we assume it is
an absolute url. Okay, we guess it wrong, but it is the page author that uses a
deprectated form of an relative url. Then we give an error message. Nothing
silly about that. What could be wrong about an internal server called "images"?

With the current implementation there are two options:

1. Evangelism: fix the site!
2. Implement the backwards compatibility thing.

Since 1. seems not to be an option for you (why not?) I suggest changing the the
subject of the bug to "Implement backwards compatibilty for deprecated relative
URLs of the form scheme:file or scheme:/path/file", put it in component
networking and assign it to me or to Bradley. We then can try our luck against
that long standing decision to not implement it.

>1. Evangelism: fix the site!
>Since 1. seems not to be an option for you (why not?) 

How could I change thousands of internet pages from other people??

When a page contains errors, MSIE shows a little yellow triangle in the status
line. You can click on it an see the details. Why not implement something like
that for pages containing errors? 
And maybe an option like the one for the javascript error: error.popup="false"
At least we try to make the web better ... if we will succeed ...

As for your other RFEs, I'm all for it, but I believe there are already bugs
filed for these. They are out of scope of this bug.

yuck
Assignee: doron → jaggernaut
Component: Browser-General → XP Apps
We finally gave in and supported those deprecated relative urls because rfc2396
allows for backwards compatibility. Fixed by checkin for bug 163225.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.