-
Notifications
You must be signed in to change notification settings - Fork 354
Set responseType based on response content-type header #562
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
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I think the |
I think you are misreading it. You can set the responseType after the headers are received. |
Well, that makes sense. Thanks a lot! Closes #561. |
Awesome! Thanks for this! :D |
2 tasks
This was referenced Jul 31, 2017
5 tasks
darrachequesne
added a commit
that referenced
this pull request
Feb 18, 2018
Some XHR implementations (like Firefox WebWorker, react-native and some Android 4.x versions) throw an exception when setting xhr.responseType = 'arraybuffer' when xhr.readyState === 2 (which is perfectly valid, spec-wise). That commit fixes that behaviour by reverting some of the changes from #562 for those implementations. Closes #590
5 tasks
darrachequesne
added a commit
that referenced
this pull request
Feb 18, 2018
Some XHR implementations (like Firefox WebWorker, react-native and some Android 4.x versions) throw an exception when setting xhr.responseType = 'arraybuffer' when xhr.readyState === 2 (which is perfectly valid, spec-wise). That commit fixes that behaviour by reverting some of the changes from #562 for those implementations. Fixes #589 Closes #590
enderson-pan
pushed a commit
to holytiny/feathersjs-wxmp-socket.io-client
that referenced
this pull request
Nov 1, 2019
Some XHR implementations (like Firefox WebWorker, react-native and some Android 4.x versions) throw an exception when setting xhr.responseType = 'arraybuffer' when xhr.readyState === 2 (which is perfectly valid, spec-wise). That commit fixes that behaviour by reverting some of the changes from socketio/engine.io-client#562 for those implementations. Fixes #589 Closes #590
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Note: the
engine.io.js
file is the generated output ofmake engine.io.js
, and should not be manually modified.The kind of change this PR does introduce
Current behaviour
Always set responseType to arraybuffer
New behaviour
Set responseType based on the reponse headers
Other information (e.g. related issues)