Closed Bug 201378 Opened 22 years ago Closed 22 years ago

URL: usage of ""

Categories

(Core :: DOM: HTML Parser, defect)

x86
Linux
defect
Not set
normal

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 . . .
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 ""
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
So it's correct for a link, but not for a form submit? yeesh.
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
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.