Closed Bug 317254 Opened 17 years ago Closed 15 years ago

[FIX]Redirect (meta refresh) doesn't escape URL, seems to do a lossy UTF-16 to ASCII conversion instead

Categories

(Core :: DOM: Core & HTML, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: jruderman, Assigned: bzbarsky)

References

()

Details

(Keywords: intl, regression)

Attachments

(1 file)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

Steps to reproduce:
1. Load http://www.linuxshare.ru/tmp/ffox/index.cgi?item=%F1%CE%D5%D3
2. Wait for the page to refresh.

Result: Firefox 1.5RC3 loads http://www.linuxshare.ru/tmp/ffox/index.cgi?item=/=CA.  That's obviously wrong: it looks like Firefox started to send the URL as UTF-16 without escaping, then sent the URL through a lossy UTF-16-to-ASCII converter.

Expected: Load http://www.linuxshare.ru/tmp/ffox/index.cgi?item=%F1%CE%D5%D3 again (I think).

In contrast, Firefox 1.0.7 loads http://www.linuxshare.ru/tmp/ffox/index.cgi?item=%D0%AF%D0%BD%D1%83%D1%81, which is correct except that it's encoded as UTF-8 instead of what the site expects (KOI8-R, I think).  Despite that, I think there's some way this breaks sites that worked correctly in Firefox 1.0.7 based on the way Igor N. Avtaev described the bug.

Originally reported by Igor N. Avtaev:
http://www.squarefree.com/burningedge/2005/11/11/2005-11-11-branch-respin/#comment-3037
http://www.squarefree.com/burningedge/2005/11/11/2005-11-11-branch-respin/#comment-3057
Note that this testcase is INVALID HTML document. On HTML document, we cannot use non-ASCII character for URI values. The HTML author MUST use escaped URI in URI values.

But of course, we need to fix this quirks if we can do it.
-> default owner
Assignee: darin → nobody
Component: Networking: HTTP → Networking
QA Contact: networking.http → networking
Version: 1.8 Branch → Trunk
Is there any interest in taking a fix for this regression?

Is this in the right component?
Yes and "probably not given the link in comment 1".

We used to just convert the URI to UTF8.  Maybe we should go back to doing that.  
Component: Networking → DOM
QA Contact: networking → general
Attached patch Like soSplinter Review
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #281327 - Flags: superreview?(jst)
Attachment #281327 - Flags: review?(jst)
This just restores the old behavior.  We _could_ try to encode using the page charset, I suppose, but I'm not sure we want to.
Blocks: 288921
Summary: Redirect (meta refresh) doesn't escape URL, seems to do a lossy UTF-16 to ASCII conversion instead → [FIX]Redirect (meta refresh) doesn't escape URL, seems to do a lossy UTF-16 to ASCII conversion instead
Comment on attachment 281327 [details] [diff] [review]
Like so

r+sr=jst
Attachment #281327 - Flags: superreview?(jst)
Attachment #281327 - Flags: superreview+
Attachment #281327 - Flags: review?(jst)
Attachment #281327 - Flags: review+
Comment on attachment 281327 [details] [diff] [review]
Like so

Requesting approval.  This should be a very low-risk change to restore behavior we used to have back in the 1.7 timeframe.
Attachment #281327 - Flags: approval1.9?
Attachment #281327 - Flags: approval1.9? → approval1.9+
Checked in.  We still need a test, though.  I could use some help writing one, to be honest.
Flags: in-testsuite?
Marking as fixed, we have the in-testsuite flag to track the lack of test. Please reopen if there are other issues remaining.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
This should have been marked fixed, yeah.  Not sure why that failed.
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.