Steps to reproduce: 1. Create an asynchronous XMLHttpRequest for an empty file with responseType set to 'arraybuffer'. 2. Send the request. 3. When the request finishes loading successfully (req.readyState is 4, req.status is 200), req.response will be set to NULL. Expected behavior: Since I requested an ArrayBuffer representation of an empty file and that request *succeeded*, req.response should be an ArrayBuffer of size 0. Code: window.addEventListener('load', function() { var req = new XMLHttpRequest(); req.open('GET', './empty.txt', true); req.responseType = 'arraybuffer'; req.onload = function(e) { if (req.readyState === 4 && req.status === 200) { // The request succeeded! // In non-WebKit browsers, req.response will be an ArrayBuffer of byteLength 0. // In WebKit browsers (Chrome/Safari), req.response will be NULL. } }; req.send(); }); A live demo of this test code can be seen here: http://people.cs.umass.edu/~jvilk/empty_xhr_bug.html Firefox and Opera (Presto engine) both set response to a 0-length ArrayBuffer. I have yet to test IE10.
Apologies for the irrelevant addEventListener call in my code snippet; I copypasta'd the snippet from the demo page, and forgot to remove it.
Apologies for mentioning Chrome; I forgot about the Blink transition. The Chrome 31 beta actually fixes this bug, but Safari 6.1 and Opera 17 still have the issue.
Thank you for the report. > The Chrome 31 beta actually fixes this bug That's a useful pointer, we can save some time by simply taking the fix and not re-doing it. https://chromium.googlesource.com/chromium/blink.git/+/aaeae38f24f53918cf66c1a16845777068d1e510
Created attachment 215451 [details] proposed fix Code fix turned out to be non-mergeable, but I used their test (with some tweaks).
Comment on attachment 215451 [details] proposed fix Rejecting attachment 215451 [details] from commit-queue. Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.appspot.com', '--bot-id=webkit-cq-03', 'apply-attachment', '--no-update', '--non-interactive', 215451, '--port=mac']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit Last 500 characters of output: chanize/_urllib2_fork.py", line 332, in _call_chain result = func(*args) File "/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/thirdparty/autoinstalled/mechanize/_urllib2_fork.py", line 1170, in https_open return self.do_open(conn_factory, req) File "/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/thirdparty/autoinstalled/mechanize/_urllib2_fork.py", line 1118, in do_open raise URLError(err) urllib2.URLError: <urlopen error [Errno 8] nodename nor servname provided, or not known> Full output: http://webkit-queues.appspot.com/results/17088317
Comment on attachment 215451 [details] proposed fix Clearing flags on attachment: 215451 Committed r158333: <http://trac.webkit.org/changeset/158333>
All reviewed patches have been landed. Closing bug.
Looks like this patch broke the following two XHR tests on Mavericks? http/tests/xmlhttprequest/response-encoding.html http/tests/xmlhttprequest/xmlhttprequest-overridemimetype-content-type-header.html http://webkit-test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=http%2Ftests%2Fxmlhttprequest%2Fresponse-encoding.html%2Chttp%2Ftests%2Fxmlhttprequest%2Fxmlhttprequest-overridemimetype-content-type-header.html e.g. http://build.webkit.org/results/Apple%20Mavericks%20Release%20WK1%20(Tests)/r158333%20(267)/results.html
Tracked as bug 123548 now. The code change was fine, but the test uncovered an unrelated bug. Surprising that EWS didn't report this - it saw that the tests became "flaky". We should probably disable retries on EWS.