Closed
Bug 201378
Opened 22 years ago
Closed 22 years ago
URL: usage of ""
Categories
(Core :: DOM: HTML Parser, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 106912
People
(Reporter: rdingman, Assigned: darin.moz)
References
()
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
The hypertext link is incorrect
Reproducible: Always
Steps to Reproduce:
1.Go to web site:
http://www.opto22.com/ordering/ItemSearch.asp?SearchString=g4oac5&submit.x=0&submit.y=0&submit=Search&Cat1=15&Cat2=24
2.Place mouse pointer over "Online Ordering" on left side of page (within the
"Ordering" box).
3. Note hypertext link shown in bottom bar of Mozilla.
Actual Results:
The link is to the current web page.
Expected Results:
The link should be as follows:
http://www.opto22.com/ordering/
The correct link appears in NS 4.79 for Linux and IE6.
I'm not sure where this bug report belongs--sorry. It appears as though it might
be javascript but . . .
![]() |
||
Comment 1•22 years ago
|
||
The HTML is:
<a href="" class="leftnavtitle">Online Ordering</a>
darin, this has come up before, but I can't recall what the resolution of that
debate was... what should an empty relative URL resolve to?
In any case, this has nothing to do with JS.
Assignee: rogerl → darin
Component: JavaScript Engine → Networking
QA Contact: pschwartau → benc
I used to use http://www.ics.uci.edu/%7Efielding/url/test1.html as a reference,
but it is down right now.
Summary: hypertext link is incorrect → URL: usage of ""
Comment 3•22 years ago
|
||
RFC 2396 states:
4.2. Same-document References
A URI reference that does not contain a URI is a reference to the
current document. In other words, an empty URI reference within a
document is interpreted as a reference to the start of that document,
and a reference containing only a fragment identifier is a reference
to the identified fragment of that document. Traversal of such a
reference should not result in an additional retrieval action.
However, if the URI reference occurs in a context that is always
intended to result in a new request, as in the case of HTML's FORM
element, then an empty URI reference represents the base URI of the
current document and should be replaced by that URI when transformed
into a request.
*** This bug has been marked as a duplicate of 106912 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Component: Networking → Parser
QA Contact: benc → moied
Resolution: --- → DUPLICATE
Reporter | ||
Comment 5•22 years ago
|
||
I'm not sure I appreciate the semantics of "However, if the URI reference occurs
in a context that is always intended to result in a new request . . .". It
appears to not be limited to the case of HTML FORMs.
But yeesh--I agree with Benc.
Mozilla 1.3 appears to comply with this spec for the link I provided:
http://www.opto22.com/ordering/ItemSearch.asp?SearchString=g4oac5&submit.x=0&submit.y=0&submit=Search&Cat1=15&Cat2=24
but perhaps it obtains this correct URI only because there is no clearly-defined
base URI.
[from RFC 2396]
5.2. Resolving Relative References to Absolute Form
This section describes an example algorithm for resolving URI
references that might be relative to a given base URI.
The base URI is established according to the rules of Section 5.1 and
parsed into the four main components as described in Section 3. Note
that only the scheme component is required to be present in the base
URI; the other components may be empty or undefined. A component is
undefined if its preceding separator does not appear in the URI
reference; the path component is never undefined, though it may be
empty. The base URI's query component is not used by the resolution
algorithm and may be discarded.
For each URI reference, the following steps are performed in order:
1) The URI reference is parsed into the potential four components and
fragment identifier, as described in Section 4.3.
2) If the path component is empty and the scheme, authority, and
query components are undefined, then it is a reference to the
current document and we are done. Otherwise, the reference URI's
query and fragment components are defined as found (or not found)
within the URI reference and not inherited from the base URI.
. . .
This example provided in RFC 2396 shows that the reference is to the current
document irrespective of whatever base URI exists. This contradicts RFC 1808
which states: "An empty reference resolves to the complete base URL . . ."
W3C HTML 4.01 states that RFC 2396 "updates" RFC 1808. If we assume "updates"
means that RFC 2396 takes precedence over RFC 1808, then Mozilla 1.3 is
non-compliant with the newer spec.
For example, in the link that Benc suggested:
http://www.ics.uci.edu/%7Efielding/url/test1.html, the base URI is clearly
defined within the document as: <base href="http://a/b/c/d;p?q">. However, for
the relative URI of
href = "",
the parser resolves the URL to <base href="http://a/b/c/d;p?q"> (the base URI)
instead of to the current page
(http://www.ics.uci.edu/%7Efielding/url/test1.html) as specified in RFC 2396.
Furthermore, to properly use the base URI it should drop the query from it as
per RFC 2369 section 4.2 (quoted above):
". . . The base URI's query component is not used by the resolution algorithm
and may be discarded."
To my reading, this is rather poor specmanship. Shall the query be discarded or not?
So to summarize,
1. the bug I reported is invalid; mozilla 1.3 returns the correct URI according
to RFC 2369.
2. Mozilla 1.3 does not consistently follow RFC 2369, at least apparently when a
base URI is embedded in the document.
3. Mozilla 1.3 may be non-compliant with RFC 2369 in its resolution of the base
URI (i.e., in not dropping the query portion from the base URI).
Points 2 & 3 do not arise directly from this bug report. Bug report
http://bugzilla.mozilla.org/show_bug.cgi?id=106912 appears to be badly-worded
from the start and these points do not directly arise from it either.
Should I pursue either point 2 or 3 in a new (possibly) bug report?
Thanks,
Bob
Comment 6•22 years ago
|
||
Point 2 is covered by bug 146441, though it probably needs a new testcase to
cover both the <a href="#target"> and <a href=""> cases. Not sure about point 3.
You need to log in
before you can comment on or make changes to this bug.
Description
•