Anchors and BASE conflict

RESOLVED DUPLICATE of bug 275689

Status

()

P2
major
RESOLVED DUPLICATE of bug 275689
17 years ago
14 years ago

People

(Reporter: donguana, Assigned: harishd)

Tracking

({testcase})

Trunk
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
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.
(Reporter)

Comment 1

17 years ago
Created attachment 84765 [details]
Sample of the base and anchor conflict
<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
(Reporter)

Comment 5

17 years ago
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...

Comment 10

17 years ago
+cc andreas.

Comment 11

17 years ago
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. ***
->Parser
Assignee: new-network-bugs → harishd
Component: Networking → Parser
Keywords: testcase
QA Contact: benc → moied
(Reporter)

Comment 14

16 years ago
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?

Updated

16 years ago
Priority: -- → P2
QA Contact: moied → dsirnapalli

Comment 15

16 years ago
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?

Comment 16

14 years ago
*** Bug 221915 has been marked as a duplicate of this bug. ***

Comment 17

14 years ago

*** 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.