I'm not sure if this is a bug or not - I checked the w3c and could not find any information on this. If I create an html page containing images and I want to send it to someone, so I place a <BASE> tag so that the user receiving the html code can see how the page was intended to look by loading the images from my server. By placing the BASE tag it messes up the anchors linking to content within the page. In this case I don't store the html content on the server only the images. So when the user clicks on an anchor there come to my server and get a "page not found" error. I tested this with other browsers and they all do the same logic but I don't think the logic is correct. I will send a sample as an attachement.
<URL:http://www.w3.org/TR/html401/struct/links.html#h-12.4> Almost certainly invalid.
RFC 1808 explicitly states the current behavior to be correct, but RFC 2396 is less clear. bz?
Scratch that, this is valid. <URL:http://lists.w3.org/Archives/Public/www-html/2001Dec/0045.html> ->Networking
Assignee: harishd → new-network-bugs
Status: UNCONFIRMED → NEW
Component: Parser → Networking
Ever confirmed: true
QA Contact: moied → benc
On the page specified above there is the following text: "When the link is defined in the same document: #anchor-one" If the link is in the same document then why should it append the base-source to the anchor?
Ugh. RFC 2396 makes this suck... <a href="#foo"> and <form action="#foo"> should load different(!) things, according to that, if the base href and the document href differ.
Severity: normal → major
OS: Windows 2000 → All
Hardware: PC → All
EXPN? (And action="#foo" isn't a very common idiom, is it?)
what does EXPN mean? And action="" also means a different thing from href="" according to that RFC. This latter _is_ pretty common.
EXPN == "explain", an SMTP-ism. Having re-read RFC 2396, I can only assume there's a good reason for section 4.2...
We should go with RFC2396, we do it nearly everywhere else in necko. However this can not be solved within the scope of networking/necko. Necko takes a base url and a string and resolves that into a new url (::Resolve). Which url is given as base is up to the caller, in this case I think the htmlparser or layout/content. This part of RFC2396 has to be implemented there.
*** Bug 136811 has been marked as a duplicate of this bug. ***
Assignee: new-network-bugs → harishd
Component: Networking → Parser
QA Contact: benc → moied
I did some more test and it is also related to the mime header "Content-Base:" in an email. I beleive the "Content-Base:" is similar to using the <BASE> tag. I'm not sure if I'm correct with this assumption. Here is a test to demonstrate this problem 1 - Go to the following url. http://www.mozilla.org/quality/browser/standards/html/a_name.html#anchor 2 - Go file -> send page 3 - Send the page to yourself 4 - Check you mail 5 - Place your browser in offline mode 6 - Look the the page that you just sent to yourself and follow the instructions on the test. 7 - You will no be able to click on the link because of the anchor. Is there any way around this bug?
As another test case of the original bug (not the mime-header-related phenomenon) have a look at: the "<>" hypertext link in the "Abnormal Examples" section on http://www.ics.uci.edu/%7Efielding/url/test1.html In this example, <base href="http://a/b/c/d;p?q"> is embedded in the document yet Mozilla 1.3 uses it to resolve the URI. Sections 4.2, 5.2 step 2), and C.2 of RFC 2396 clearly state that "An empty reference refers to the start of the current document." Presumably, this behaviour is 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. What confuses the issue for me, however, is the "however" caveat in section 4.2 of RFC 2396. The "however" does not appear limited to HTML FORMS: [from RFC 2396] 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. If one were to interpret this to mean that any URI reference occurs "in a context that is always intended to result in a new request", then the empty URI should always be replaced by the base URI of the current document. I don't think that is what was intended by this caveat, but it raises the question of how an HTML parser is supposed to know that level of detail about a URI's context? This material is new to me so maybe the context is more apparent than I realize, but the spec seems a little ambiguous on this point. Any thoughts?
*** Bug 221915 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of 275689 ***
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.