Skip to content

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
merged 3 commits into from
Apr 24, 2017

Conversation

Nibbler999
Copy link

Note: the engine.io.js file is the generated output of make engine.io.js, and should not be manually modified.

The kind of change this PR does introduce

  • a bug fix
  • a new feature
  • an update to the documentation
  • a code change that improves performance
  • other

Current behaviour

Always set responseType to arraybuffer

New behaviour

Set responseType based on the reponse headers

Other information (e.g. related issues)

@darrachequesne
Copy link
Member

darrachequesne commented Apr 23, 2017

I think the responseType must be set before firing the request (reference), hence the current state (supportsBinary & content-type cases).

@Nibbler999
Copy link
Author

I think you are misreading it. You can set the responseType after the headers are received.

@darrachequesne darrachequesne merged commit 3e03346 into socketio:master Apr 24, 2017
@darrachequesne
Copy link
Member

Well, that makes sense. Thanks a lot!

Closes #561.

@stephank
Copy link

Awesome! Thanks for this! :D

@darrachequesne darrachequesne added this to the 3.1.0 milestone Apr 27, 2017
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
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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants