Setting XMLHttpRequest.responseType forbidden all of a sudden?

Question

I've been using synchronous XMLHttpRequest with responseType set to "arraybuffer" for quite a while to load a binary file and wait until it is loaded. Today, I got this error: "Die Verwendung des responseType-Attributes von XMLHttpRequest wird im synchronen Modus im window-Kontekt nicht mehr unterstützt." which roughly translates to "Usage of responseType for XMLHttpRequest in synchronous mode in window-context(?) no longer supported."

Does anyone know how to fix this? I realy don't want to use an asynchronous request for something like this.

var xhr = new XMLHttpRequest();
xhr.open('GET', url, false);
xhr.responseType = 'arraybuffer';

Works fine in chrome.

You can do binary synchronous XHR's in Web Workers... – Janus Troelsen May 18 '13 at 13:44 — Janus Troelsen, May 18 '13 at 13:44

score 14 · Accepted Answer · answered Mar 24 '12 at 20:28

14

This is correct behaviour, as defined in the Specification of XMLHttpRequest:

When set: throws an "InvalidAccessError" exception if the synchronous flag is set and there is an associated XMLHttpRequest document.

The responseType property cannot be set when the XMLHttpRequest is not async, that is, synchronous. Setting the third parameter of open to false causes the request to be synchronous.

answered Mar 24 '12 at 20:28

Rob W

341,306
83
791
678

1

Sounds weird to me that something like that is supposed to throw an exception. But thanks for pointing me to the specification. – Markus Mar 24 '12 at 20:30
4

@Markus The point is that you shouldn't be writing new code that uses sync XHR. Removing it altogether would break existing sites, but browsers and the spec are trying to restrict its use in new code so that new code actually does the right thing and uses async XHR. – Boris Zbarsky Mar 25 '12 at 04:51
crippling the platform for no reason, the hate is mutual – capr Mar 27 '23 at 00:16

Stephan · Answer 2 · 2017-06-27T08:40:53.013

Workaround

For the casual reader, if you still need the synchronous behavior, you can download your content as string and then convert it to byte data

NOTA:
This workaround assumes the original request.response is an ASCII text.
If this assumption doesn't fit your specific use case please see jBinary.

I convert it to an ArrayBuffer.

var request = new XMLHttpRequest();
request.open('GET', url, false);
request.send(null);

var data;
if (request.status === 200) {
    data = stringToArrayBuffer(request.response);
} else {
    alert('Something bad happen!\n(' + request.status + ') ' + request.statusText);
}

// ...

function stringToArrayBuffer(str) {
    var buf = new ArrayBuffer(str.length);
    var bufView = new Uint8Array(buf);

    for (var i=0, strLen=str.length; i<strLen; i++) {
        bufView[i] = str.charCodeAt(i);
    }

    return buf;
}

References

Converting between strings and ArrayBuffers
Renato Mangini's original function str2ab
Easier ArrayBuffer <-> String conversion with the Encoding API (Jeff Posnik)

Is there a way to retrieve the original binary (non-ascii) binary data exactly? — Tamas Hegedus, Mar 10 '16 at 02:24
@TamasHegedus To answer your question, I have updated my post with a **More reading** section. — Stephan, Mar 10 '16 at 09:13
I am suspicious about the binary-text-binary conversion not yielding the original bytes — Tamas Hegedus, Mar 10 '16 at 16:17
@TamasHegedus The workaround presented here works *only* with the assumption the original bytes are encoded in ASCII. — Stephan, Jun 27 '17 at 08:39

iman · Answer 3 · 2020-09-16T13:03:26.220

As it's not possible to set responseType = 'arraybuffer' in sync mode, receiving string and converting to bytes is a solution, but as Stephan said, your data should be an ascii text. You will receive wrong value (253) instead of all bytes above 127.

But setting mime-type and charset to x-user-defined might be a solution:

Here server send 10 bytes from 125 to 134:

request = new XMLHttpRequest();
request.overrideMimeType('text/plain; charset=x-user-defined');
request.open('GET', url, false);
request.send();
Uint8Array.from(request.response, c => c.charCodeAt(0));
> Uint8Array(10) [125, 126, 127, 128, 129, 130, 131, 132, 133, 134]

without setting mime-type it's like this:

request = new XMLHttpRequest();
request.open('GET', url, false);
request.send();
Uint8Array.from(request.response, c => c.charCodeAt(0));
> Uint8Array(10) [125, 126, 127, 253, 253, 253, 253, 253, 253, 253]

This answer is best for me! using 'overrideMimeType' is a solution — Pavlikooo, Aug 10 '22 at 07:00

score 0 · Answer 4 · edited Dec 31 '18 at 06:56

If you're lucky enough to have control over the entry point of the whole page, consider wrapping the whole thing with an async function and using await to block on problematic asynchronous code. Might not work with all use cases though.

(async function () {
    await problem_function_1();
    await problem_function_2();
    ... normal page logic pasted here ...
})();

Wrap async code that is not a promise with a Promise (so that await works as expected), and call the resolve function manually in whatever constitutes a "success callback". Do the same for reject if possible.

Setting XMLHttpRequest.responseType forbidden all of a sudden?

4 Answers4

Workaround

More reading

References

Linked

Related