Closed Bug 202472 Opened 21 years ago Closed 21 years ago

<base> tag with non absolute HREF's are ignored

Categories

(Camino Graveyard :: Page Layout, enhancement)

PowerPC
macOS
enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 553074

People

(Reporter: scott, Assigned: bryner)

References

()

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/73 (KHTML, like Gecko) Safari/73
Build Identifier: Camino 0.7 Build ID: 2003041005

The HTML 4 spec says that the HREF attribute of the BASE head tag can be either an absolute or a 
relative URL that specifies the new base URL for all relative links or other HREFS on the page. 
However, Camino appears to accept only base tags with HREF's that are not only absolute server 
paths but also include the http and server portion as well.

The following three links should all render properly and correctly resolve all included images:
http://www.lakeshorechurch.org/index.html    -> base href=http://www.lakeshorechurch.org/
main/
http://www.lakeshorechurch.org/broken1.html -> base href=/main/
http://www.lakeshorechurch.org/broken2.html -> base href=main

In Safar Beta 2 (v73) and IE on Mac OS X, all three are displayed correctly. However, in Camino, only 
index.html displays correctly

Reproducible: Always

Steps to Reproduce:
1. Create a page with a base tag that isn't absolute including http and server name
2.
3.
Actual Results:  
Camino treats all relative links as if there was no base tag

Expected Results:  
Used the base tag as a relative extension to the page location
I think the value of the href attribute for the base element is required to be
an absolute URI (somebody can correct me if I'm wrong). I imagine that the page
loads correctly in Safari and IE because they ignore the invalid base element
and resolve the relative URIs from the current page address. Camino must always
follow the base href, regardless of whether it's valid or not.

I was able to reproduce on Mozilla 1.3 (Mac OS X 10.2.5), but somebody better
than me will have to decide whether Mozilla should be so strict about trying to
resolve invalid base URIs and confirm/reassign this bug (or mark invalid/wontfix
if this is the intended behavior). This isn't Camino specific, however.
Ok, I went and looked at the HTML 4.0.1 spec at the W3C's web site:

http://www.w3.org/TR/html4/struct/links.html#edef-BASE

Adam is indeed correct, and the "HTML definitive reference" (or whatever that book I have at 
work is actually called) is wrong.

In the event that Mozilla desires to handle incorrect HTML, I've changed this the severity of this to 
"enhancement" However, I'll leave it up to all of you to decide whether to pass this up the Mozilla 
tree or not.
Severity: major → enhancement
Technically speaking, no, Mozilla.org does not implement new behaviors that
aren't standards compliant. Mozilla.org sometimes does so if large, high-traffic
sites have used the behavior in the past and so implementing it would help
backwards compatibility. However, this isn't one of those cases.

Resolving WONTFIX.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
Resolution: WONTFIX → DUPLICATE
You need to log in before you can comment on or make changes to this bug.