22894 - Partial URLs with scheme (e.g., http:page.html) do not load

Status: VERIFIED DUPLICATE of bug 22251

(Core :: Networking, defect, P3)

Description

[Sean Richardson]

Overview:
The first link on this Contents page, to the Preface, coded as
<a href="http:preface.html">Preface</a>,
is transformed into "http://preface.html/" in the Location bar by Mozilla
instead of the intended "http://www.tuxedo.org/~esr/writings/taoup/preface.html"

Also, the Contents page is not only still visible after "http://preface.html/"
fails to load, but the "Preface" link still works, so additional attempts
pile up in the Session History - clicking on [Back] as many times does work
to return to the Contents page, but no feedback is given in the state of the
Location Bar widgets that anything is happening.

Steps to reproduce.
1. Load the page at the URL above (the "Contents page").
2. Click on the first link, "Preface".
3. Observe the throbber, spinner, Location Bar, and the title.
4. Repeat step 2 a few times.
5. Click on [Back] as many times, then once more.

Actual Results:
A. The Location bar immediately shows "http://preface.html/".
B. The throbber and spinner will be active for a while, then the [Stop] button
   grays.
C. The Contents page will still be visible, and the Title bar will not show
   "Preface".
D. The Contents page will remain visible through Step 4.
E. The [Back], [Forward], [Reload] and [Stop] buttons give no feadback during
   step 5, until the Contents page is reached again.

Expected Results:
A. The Preface page, at "http://www.tuxedo.org/~esr/writings/taoup/preface.html"
   will load, and the title bar will change to "Preface".
B. [Back]-navigation will work normally.

Does not work correctly with:
2000-01-01-08-M13 nightly binary on Windows NT 4.0sp3

Works correctly with:
NN 4.7 on Windows NT 4.0sp3

Additional Information:
The relevant spec seems to be in section 5.2 of RFC 2396,
"Uniform Resource Identifiers (URI): Generic Syntax",
<URL:http://www.ietf.org/rfc/rfc2396.txt>,
which specifies steps to be taken to resolve relative URLs.

The RFC discusses URLs of the form "http:preface.html" as follows:
  >(3) 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.
This workaround is probably needed, early in the URL parsing.

This is the converse of bug 19917, "4.xP Partial URLs of the form
//hostname/path resolved wrongly", were the scheme is left out and the
<net_path> and <path_segments> are left in.

[e-mail], does the link to the "Preface" page work
for you with the local fixes you made for bug 19917, or does this need
more coding yet?

QA: the problems with the SH observed after step 3 are almost certainly a
distinct bug unrelated to the URL parsing code, but once the URL parsing is
fixed, these problems are almost certain to be masked. This should really
be a new bug, but who should get it? The same sort of problem showed up
in bug 21005, "Unclosed <TITLE> completely blocks painting of canvas", before
it was fixed (Actual Results:B) and in at least one other fixed bug, and
apparently will continue to get triggered whenever the URL loading gets
confused. Without its own report, this problem will never get fixed because
the fix for new page loading problems will always mask it again.

Comment 1

[John Morrison]

The 'http:page.html' issue is bug #22251. No?

Comment 2

[Sean Richardson]

Yes, this is bug 22251 again - but this seems to have nothing to do with
the <BASE> element - the same problem happens here without it.

Marking this as a DUP of 22251.

[e-mail], any ideas who should catch the problem of the
previous page still being active, and the SH piling up load attempts?
I'll write that up as a new bug for clarity - if I haven't done that
by the time you are ready to VERIFY, this should show up in the diff
to remind me!


*** This bug has been marked as a duplicate of 22251 ***

Comment 3

[Andreas Otte]

No, my changes will not help here as I said in bug 22251. This one is really
nasty, it goes completely against the current logic we have to detect relative
URLs.

Comment 4

[Neil Marshall]

Verified dupe of 22251