WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 15555
XMLHttpRequest does not support charset "x-user-defined", which can facilitate loading of binary data
https://bugs.webkit.org/show_bug.cgi?id=15555
Summary
XMLHttpRequest does not support charset "x-user-defined", which can facilitat...
Tom Robinson
Reported
2007-10-18 02:43:22 PDT
Firefox's XMLHttpRequest can load binary data by overriding the MIME type to use "x-user-defined": req.overrideMimeType("text/plain; charset=x-user-defined"); (
http://mgran.blogspot.com/2006/08/downloading-binary-streams-with.html
) WebKit's XMLHttpRequest does not support this charset, so it defaults to another, which results in some of the binary values greater than 127 being mapped to incorrect values (see the red boxes in the test case).
Attachments
proposed fix
(17.62 KB, patch)
2007-10-25 11:24 PDT
,
Alexey Proskuryakov
darin
: review+
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1
2007-10-18 02:51:30 PDT
I'm wondering if this encoding is of any use outside XHR - most likely, Firefox supports it for all page loads.
Alexey Proskuryakov
Comment 2
2007-10-25 11:24:46 PDT
Created
attachment 16860
[details]
proposed fix This matches Firefox implementation, since I couldn't find MSIE one documented anywhere (this charset is not supposed to be used on the Web, according to MSDN).
Tom Robinson
Comment 3
2007-10-25 11:42:41 PDT
But should it actually match Firefox's implementation? I'm wondering why Firefox returns the correct value OR'd with 0xF700 for values >= 0x80? Is there a good reason for this?
Alexey Proskuryakov
Comment 4
2007-10-25 11:56:09 PDT
So, what does IE do? Is its implementation of x-user-defined different in some way?
Alexey Proskuryakov
Comment 5
2007-10-25 22:41:58 PDT
In IE, responseText is trimmed at null bytes, so it apparently isn't suitable for binary data regardless of its encoding.
Darin Adler
Comment 6
2007-10-26 00:15:01 PDT
Comment on
attachment 16860
[details]
proposed fix + unsigned char c = bytes[i]; + characters[i] = (c < 0x80) ? c : 0xf700 + c; If you used "signed char" you wouldn't need to do as much math: signed char signedByte = bytes[i]; characters[i] = signedByte & 0xF7FF; + UChar32 highBits = c & 0xffffff80; + if (!highBits || highBits == 0xf780) + bytes[resultLength++] = static_cast<char>(c); And I'd just write this as: signed char signedByte = c; if (signedByte & 0xF7FF == c) bytes[resultLength++] = signedByte; r=me with or without my suggested optimization
Alexey Proskuryakov
Comment 7
2007-10-27 01:52:39 PDT
Committed revision 27145 with suggested optimizations. I guess it remains to be seen how (and whether) this change affects HTML documents...
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug