139631 - HTTP-EQUIV Refresh redirects to wrong URL

Status: VERIFIED WONTFIX

(SeaMonkey :: UI Design, defect)

Description

[andreas]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc1)
Gecko/20020417
BuildID:    2002041711

The following page is generated by Zope.
Mozilla reload http://yetix.ath.cx:8080/showPlaylist
instead of ..:8080/mp3/showPlaylist

<html>
<head>
<base href="http://yetix.ath.cx:8080/mp3/" />

<title>JukeZopx: Playlist</title>
<meta HTTP-EQUIV="refresh" content="60;URL=showPlaylist"> 
<style type="text/css" media="all">
@import "design_css";
</style>
</head>
<body>
....


Reproducible: Always
Steps to Reproduce:
1. see above
2.
3.

Expected Results:  see above

Comment 1

[Boris Zbarsky [:bzbarsky]]

Attachment: testcase

Comment 2

[Boris Zbarsky [:bzbarsky]]

On that attachment, I see identical "wrong" behavior (not using the <base href>)
in the following browsers:

Mozilla
IE5
NS4.7x
Lynx

This suggests to me that changing our behavior would lead to a compatibility
nightmare.... jag?  What do you think?

Comment 3

[Christopher Hoess (gone)]

<weasel>The data-type of the "content" attribute in HTML is CDATA, not URI.  It
could be argued that the language of
<URL:http://www.w3.org/TR/html401/struct/links.html#h-12.4> applies only to
attributes that are known to be URIs through the semantics of HTML, and that an
HTML user agent should not try to determine whether or not other attributes are
URIs.  I think the current behavior is perfectly defensible under the
recommendation.</weasel>

Comment 4

[jag (Peter Annema)]

If we fix this there could be some sites out there that currently have
content="60;url=/mp3/....." to compensate for this bug in other browsers, in
which case we'd try to load "/mp3/mp3/...". Technically, yes, we should resolve
that url relative to the specified base url, but since the behaviour of
http-equiv="refresh" is undefined, or rather defined de facto by older and
existing browsers, we should just do what everyone else does.

Won't fix?

Comment 5

[Boris Zbarsky [:bzbarsky]]

wontfix is my vote....

Comment 6

[Paul Wyskoczka]

v