146441 - Anchors and BASE conflict

Status: RESOLVED DUPLICATE of bug 275689

(Core :: DOM: HTML Parser, defect, P2)

Description

[Ian]

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.

Comment 1

[Ian]

Attachment: Sample of the base and anchor conflict

Comment 2

[Christopher Hoess (gone)]

<URL:http://www.w3.org/TR/html401/struct/links.html#h-12.4>

Almost certainly invalid.

Comment 3

[Christopher Hoess (gone)]

RFC 1808 explicitly states the current behavior to be correct, but RFC 2396 is 
less clear. bz?

Comment 4

[Christopher Hoess (gone)]

Scratch that, this is valid.

<URL:http://lists.w3.org/Archives/Public/www-html/2001Dec/0045.html>

->Networking

Comment 5

[Ian]

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?

Comment 6

[Boris Zbarsky [:bzbarsky]]

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.

Comment 7

[Christopher Hoess (gone)]

EXPN? (And action="#foo" isn't a very common idiom, is it?)

Comment 8

[Boris Zbarsky [:bzbarsky]]

what does EXPN mean?  And action="" also means a different thing from href="" 
according to that RFC.  This latter _is_ pretty common.

Comment 9

[Christopher Hoess (gone)]

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

[benc]

+cc andreas.

Comment 11

[Andreas Otte]

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.

Comment 12

[Christopher Hoess (gone)]

*** Bug 136811 has been marked as a duplicate of this bug. ***

Comment 13

[Christopher Hoess (gone)]

->Parser

Comment 14

[Ian]

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?

Comment 15

[Bob Dingman]

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

[Anne (:annevk)]

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

Comment 17

[Sjoerd Visscher]

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