Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

response vs responseText #184

Open
ra1u opened this issue May 12, 2020 · 3 comments
Open

response vs responseText #184

ra1u opened this issue May 12, 2020 · 3 comments

Comments

@ra1u
Copy link

ra1u commented May 12, 2020

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.

From: https://xhr.spec.whatwg.org/#the-responsetext-attribute about responseText

1 .If responseType is not the empty string or "text", then throw an "InvalidStateError" DOMException.

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.

@tasn
Copy link

tasn commented Jul 15, 2020

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.

@vdenisenko-waverley
Copy link

Same for me, any update on this?

@joe-jordan
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants