Closed Bug 22251 Opened 25 years ago Closed 22 years ago

chin.buffnet.net - Relative URLs with scheme (e.g., http:page.html) not loading - treated as absolute

Categories

(Tech Evangelism Graveyard :: English US, defect, P2)

Product:
Tech Evangelism Graveyard
Component:
English US
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: jcarpenter0524, Unassigned)

References

(
URL
)

Details

(Keywords: helpwanted, Whiteboard: [SYNTAX-URL][aok])

Attachments

(3 obsolete files) 

Overview Description:
This page uses <base href="http://www.chin.buffnet.net/"> for it's internal
links, but they don't work.  Attempted to recreate this problem locally, but it
worked fine on all examples...?

Steps to Reproduce:
- Go to the URL: http://www.chin.buffnet.net/
- Move down the page to a section called "Other ChinNet information"
- Click on any of the links in this section (except the last one which goes
outside the site)
- Notice in the URL bar that, for example, "Cage Designs" goes to the link:
    "http://cages.html/"
  when instead it should go to:
    "http://www.chin.buffnet.net/cages.html"

Actual Results:
internal link attemts to take you to the .html file without using the base tag
ref.
http://cages.html/

Expected Results:
expect the base tag to be inserted before the .html file name
http://www.chin.buffnet.net/cages.html


Build Date & Platform Bug Found:
1999-12-20-12 Win98

Additional Builds and Platforms Tested On:
1999-12-20-08 Linux
1999-12-20-08 Mac

Additional Information:
Priority: P3 → P2
QA Contact: gerardok → janc
changing qa assignment to janc
<html>
<head><base href="http://www.chin.buffnet.net/"></head>
<body>
   <A href="http:cages.html">Cage designs.</A>
</body></html>

Notice the 'http:cages.html' ...
Whiteboard: [TESTCASE]
Assignee: vidur → warren
Component: DOM Level 1 → Networking
The code that resolves relative URLs (NS_MakeAbsoluteURI) thinks that the value
of the href attribute of the anchor ("http:cages.html") is already an absolute
URL and doesn't do any further resolution. The attribute isn't really
well-formed, but I'll let Warren figure out whether we want to be backward
compatibile in this case.
Vidur is right: RFC 2396 says

      If the scheme component is defined, indicating that the reference
      starts with a scheme name, then the reference is interpreted as an
      absolute URI and we are done.  Otherwise, the reference URI's
      scheme is inherited from the base URI's scheme component.

      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.

Adding this backwards compatibility will be a real pain, but I will take a look.
*** Bug 22894 has been marked as a duplicate of this bug. ***
Summary: base href tag not working on this URL → Relative URLs with scheme (e.g., http:page.html) not loading - treated as absolute
As seen in bug 22894, the problem with having schemes on relative URLs
happens on pages without a <BASE> element. The base URL should be interpolated
if the page is loaded from its "home" server according to the rules in
section 5.2 of RFC 2396, "Uniform Resource Identifiers (URI): Generic Syntax",
<URL:http://www.ietf.org/rfc/rfc2396.txt>, whether or not there is a <BASE>
element.

Changing summary from "base href tag not working on this URL" to
"Relative URLs with scheme (e.g., http:page.html) not loading - treated as
absolute"
The problem here is to make the distinction between http:page.html which is
relative and rdf:bookmarks which is absolute. I tried to make nsStdURL:Resolve
smart enough to resolve http:page.html correctly, it works, but
NS_MakeAbsoluteURI (which calls Resolve) from nsNetUtil.h wants to be even
smarter and trys to detect if there is an absolute URI on its own. Removing that
stuff from NS_MakeAbsoluteURI the rdf-URIs are no longer absolute and mozilla
looks a bit ugly afterwards.

Is it possible to make rdf-URIs of the type nsSimpleURI? nsSimpleURI::Resolve
could return the string put in instead of an Assertion. Warren?
Blocks: 13449
Target Milestone: M14
I think the criterion for relative vs. absolute should be whether there's a
// (or //<something>/) or not. E.g. given a base URL of
http://foo.com/bar/baz.html and a relative URL of http:page.html,
http:/page.html, or http://page.html (with no directory portion), these should
all resolve to http://foo.com/bar/page.html. However, if the relative URL is
http://a/page.html, this should resolve to http://a/page.html (where 'a' is
interpreted as the hostname).
But this does not help with http:page.html versus rdf:bookmarks. rdf:bookmarks
is absolute. NS_MakeAbsoluteURI detects this by searching for a : in the spec,
so http:page.html is also absolute for this function.
rdf: should be using nsSimpleURI, not nsStdURL.
From looking at the sources, there seems to be a list of URIs that is read in on
startup. This can be all sort of URIs, hierachical or not (nsStdURL or
nsSimpleURI), files, chrome, http, whatever ...

rdf: is not the only problem, urn: comes to my mind, same problem ...

There is no simple fix to this. I think we need a kind of registration service
here which registers schemes mozilla knows about with some additional
information (hierachical or not, host/authentification or not). The
parser/resolver then has to react on that additional information.
I think you're getting sidetracked here. Remember that the protocol dictates
the URL parsing scheme. For rdf, it decides to use nsSimpleURI and doesn't have
this problem. But for http (and other protocols that use nsStdURL), nsStdURL
needs to treat things like "http:page.html" as a relative spec, i.e.
MakeAbsolute/Resolve need to not treat the string as if it were absolute.
You are right, it should do that, but I don't think there is such a thing as a
rdf protocol-handler or a urn protocol-handler. Regardless of that, the base URL
is in most of these cases a chrome-URI, "rdf:bookmarks" is a simple string given
to MakeAbsolute.

If we detect a scheme in the string given to Resolve we could query the
protocol-handler (if existing) for the kind of URI it would create and then act
on that.
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
Keywords: beta1
Whiteboard: [TESTCASE] → [TESTCASE][PDT+]
Andreas, Is this fixed now?
Assignee: warren → andreas.otte
Warren: No, I think we still need to think about this. Have you read my last
comments on this? We need to have a way to distinguish simple from normal uris.
Keywords: helpwanted
Okay, I implemented a GetUritype method on nsIProtocolHandler which gives some
information on the type of url that is used. This gives resolve the means to
distinguish between http:page.html (relative) and rdf:bookmarks.html (absolute).
So far it works fine, but I'm still testing ...
Status: NEW → ASSIGNED
I'm getting confused here. The Resolve method should just behave differently 
for nsStdURL vs. nsSimpleURI. Why do we need a global way to ask if something 
is relative or absolute?
Because there are places in the code where MakeAbsoluteURI/Resolve is called on
strings from a list of uris (with a std-baseurl) which can be both Simple or
Std. If it is a simple-uri to resolve (which we don't know because we only have
a string, not a uri) it is absolute, otherwise it may be relative or absolute.

Marking this bug WONTFIX per Warrens request, but I will save my set of fixes
for this problem in case it pops up again and no one has a better solution.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WONTFIX
Andreas, Please either attach your final patches for this to this bug report, or 
put a note in to say what your base and branch tags are. Thanks.
I will do that immediatly when I have made the branch.
The branch is named BUG22251_BRANCH. You also have to unzip the latest
attachement in mozilla/rdf to add the missing protocolhandlers. Mac project
files are missing.
*** Bug 29012 has been marked as a duplicate of this bug. ***
*** Bug 30707 has been marked as a duplicate of this bug. ***
Is someone working on this bug?  It is marked won't fix, but then there are 
fixes attached, and other bugs marked as duplicates of this one...  Should it be 
reopened?

By the way, here's one (likely rare) reason to reopen this bug. 
Go to http://www.ehvert.com/ That URL has does a redirect to 
http:/Ehvert/default.asp

   <meta HTTP-EQUIV="REFRESH" CONTENT="0;URL=http:/Ehvert/default.asp">

and that sets off an _infinite_ loop of redirects.

  Error loading URL http://ehvert/default.asp 
  Document: Done (0.184 secs)
  Document http://keyword.netscape.com/keyword/ehvert loaded successfully
  Document: Done (1.241 secs)
  Error loading URL http://ehvert/default.asp 
  Document: Done (0.23 secs)
  Document http://keyword.netscape.com/keyword/ehvert loaded successfully
  Document: Done (1.241 secs)

(I'm embarassed to admit that friends of mine run the company :-\). 

The fixes for this bug are on the BUG22251_BRANCH, combined with the attachement
5806. There are concerns about the way the fix is done (not from me btw.), so if
you have a better idea, feel free to submit it. For now nobody has a better idea
and so it stays as WONTFIX. 
I don't think that fixing this bug would also fix the above redirected URL:
http:/Ehvert/default.asp

It might, if the url would be changed to http:Ehvert/default.asp, but with the
above case it simply thinks this is a case of a malformed URI and trys a
correction to http://Ehvert/default.asp.

The url syntax causing this bug was deemed a heinous abuse of the spec, and 
leads to numerous other inconsistencies, so we decided not to fix it. 
Perpetrators should adjust their pages.
I realize that I didn't look closely enough at the URL http:/Ehvert/default.asp
and that it is a different thing than the http:page.html kind of problem. 
Apologies. 

However, this URL does lead to an infinite loop of redirects (yes, this is in 
error, and is probably extremely rare). Do you want me to file a separate bug
for this? (perhaps an upper bound on the number of redirects?)


John, have a look at bug 26438 - jst@netscape.com just nailed a problem with
infinite reloads with bad syntax in a <meta HTTP-EQUIV="REFRESH" ...> element,
and it's possible that fix will solve the problem at http://www.ehvert.com/

A hard limit on either the number of refreshes that will be done between non-
refresh page loads, or the number that will be done within one minute, makes
sense as a fallback for the unknown panoply of ways to get an infinite refresh
sequence started - some of which may not be explainable as bugs or unfollowed
specs.
Ok, marking verified
Status: RESOLVED → VERIFIED
*** Bug 32803 has been marked as a duplicate of this bug. ***
*** Bug 36821 has been marked as a duplicate of this bug. ***
*** Bug 48014 has been marked as a duplicate of this bug. ***
as submitter of bug 48014, two comments:

1) I agree with warren@netscape.com that http:foo.html is ugly,
although andreas's quote from rfc2396 indicates that it's allowed
to be interpreted as local in hierarchial urls (like http://)

2) given that both NS (<6) and IE interpret it as releative and there
are probably millions of pages out there that use that fact,
I expect that you'll be very, very sorry to take a hard-line interpretation
on the spec on this one.  (For example, consider the 4 times this has been
submitted as a bug)

because of (2), I suggest you consider reopening this bug.

Just wanted to point out that O'Reilly book by Musciano
 "HTML: The Definitive Guide" 1996 on page 177 gives example:

ftp:special/README.txt

I know it is an old book, but there are a lot of peope still using it, so maybe
support for it is needed.
*** Bug 62624 has been marked as a duplicate of this bug. ***
*** Bug 58204 has been marked as a duplicate of this bug. ***
*** Bug 60308 has been marked as a duplicate of this bug. ***
*** Bug 50629 has been marked as a duplicate of this bug. ***
*** Bug 69722 has been marked as a duplicate of this bug. ***
*** Bug 70886 has been marked as a duplicate of this bug. ***
*** Bug 75807 has been marked as a duplicate of this bug. ***
*** Bug 82365 has been marked as a duplicate of this bug. ***
*** Bug 83269 has been marked as a duplicate of this bug. ***
For the last 6 months we are having at least a dup per month (see also bug 84450)
 
This feature works fine on MSIE, NS<6, Opera, Konqueror and Lynx.

Are we sure we wont fix this ?
Are we doing the right thing and all these other browsers are wrong ?

Maybe it is time to take again a look at the fixes to this bug on the
BUG22251_BRANCH. Of course they are totally bit rotted by now. But the dup bug
count on this stuff is very high. I'm really surprised how much this deprecated
relative urls are still being used.  
Some dups of this bug are hidden because they are classified as component 
"Evangelism" ( see bug 65650 and bug 84450 )

Bug 32966 is *very* related to this bug and also has a long list of duplicates.

It wont be easy to "evagelize" all these people.
I know the main issue here seems to be http: (which I think is silly). But what
about the issue of having an href="?query". It seems a lot of sites do this and
expect that a browser will put the curent url in there... but mozilla is nice
enough to leave off the page. So say you were at
http://www.blah.com/somedir/index5.php and there is an href="?blah=value" then
moziall does a http://www.blah.com/somedir/?blah=value. I did not test to see
what it does with # but I think it is an agreement that this is not correct.

I do think it is bad coding on these peoples part to write code like this but at
the same time so darn many people do it it becomes annoying when browsing sites.
Which build do you use? The query handling has been changed after 0.9.3 back to
the pre 0.9.2 behaviour.
Mozilla 0.9.3
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801
Okay, then it's clear. Just wait for 0.9.4 and all will be well again. However
it is sad that we have two milestones with the different query behaviour
including Netscape 6.1. But changing it was okay according to RFC 2396 (Opera
does it also this way) and we found only later out that the authors of RFC 2396
did not meant what they had written :), so we changed it back ...

Sometimes things have to go back and forth a few times before the right solution
is found. Thanks for spending some of your valuable time on this for me. I will
be looking forward to all that 0.9.4 has to offer :)
*** Bug 99263 has been marked as a duplicate of this bug. ***
sending this old thing to Tech Evang
Status: VERIFIED → REOPENED
Component: Networking → English: US
Product: Browser → Tech Evangelism
Resolution: WONTFIX → ---
Target Milestone: M14 → ---
Version: other → unspecified
reassigning
Assignee: andreas.otte → bclary
Status: REOPENED → NEW
QA Contact: janc → zach
Summary: Relative URLs with scheme (e.g., http:page.html) not loading - treated as absolute → chin.buffnet.net - Relative URLs with scheme (e.g., http:page.html) not loading - treated as absolute
sent an email to webmaster@chinnet.net
Assignee: bclary → _basic
Keywords: helpwanted, testcase
Whiteboard: [TESTCASE][PDT+] → [REL-URL]
No longer blocks: 13449
Whiteboard: [REL-URL] → [SYNTAX-URL]
changign to assigned since emailw as sent
Status: NEW → ASSIGNED
Whiteboard: [SYNTAX-URL] → [SYNTAX-URL][aok]
*** Bug 121350 has been marked as a duplicate of this bug. ***
*** Bug 139872 has been marked as a duplicate of this bug. ***
assigning to nobody
Assignee: basic → nobody
Status: ASSIGNED → NEW
Keywords: helpwanted
The fix for bug 32966 also fixes this issue.
Depends on: relative-http
Attachment #5209 - Attachment is obsolete: true
Attachment #5806 - Attachment is obsolete: true
Attachment #42332 - Attachment is obsolete: true
This is now fixed with the checkin for bug 32966.
Status: NEW → RESOLVED
Closed: 25 years ago → 22 years ago
Resolution: --- → FIXED
v
Status: RESOLVED → VERIFIED
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: