You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems that when received type is json then response is null and responseText is json text, but from my understanding of standard it should be vice versa.
I also got bitten by a similar issue. It seems like response is not supported at all (I also took a look at the code). I'm fetching binary data and getting the response in responseText as a binary-looking string.
In the process of writing a workaround for this bug (passing the responseText.charCodeAt(i) into an ArrayBuffer), I've discovered the following:
Some data is unrecoverable in the incoming packet. Any byte which doesn't map to a known unicode code point gets mapped to 0xFFFD, i.e. https://www.fileformat.info/info/unicode/char/fffd/index.htm, which means you don't know what the actual response contained.
If anyone knows of a patched version of this library, or a workaround that actually works, it would be good to mention it here, since the project seems to be inactive.
It seems that when received type is
json
thenresponse
is null andresponseText
is json text, but from my understanding of standard it should be vice versa.From: https://xhr.spec.whatwg.org/#the-responsetext-attribute about
responseText
I am also not sure that I am looking at correct standard. Let me know where can I find text of standard that this library is based on.
The text was updated successfully, but these errors were encountered: