Bug 123457 – XHR.response is null when requesting empty file as arraybuffer

• Status: RESOLVED
• Resolution: FIXED
• Component: XML

[John Vilk]

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.

[John Vilk]

Apologies for the irrelevant addEventListener call in my code snippet; I copypasta'd the snippet from the demo page, and forgot to remove it.

[John Vilk]

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.

[Alexey Proskuryakov]

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

[Alexey Proskuryakov]

Created attachment 215451 [details]
proposed fix

Code fix turned out to be non-mergeable, but I used their test (with some tweaks).

[WebKit Commit Bot]

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

[WebKit Commit Bot]

Comment on attachment 215451 [details]
proposed fix

Clearing flags on attachment: 215451

Committed r158333: <http://trac.webkit.org/changeset/158333>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Ryosuke Niwa]

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

[Alexey Proskuryakov]

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.