Transport options/headers for server-to-server use case #534
Conversation
This file contains 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
…Useful if you need to pass headers for example to an XHR request
…ransport-headers
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.
This PR adds support for passing additional transport options like headers for all transports except websockets and also receiving an
infoevent when the /info response is received.The use case here is to support cookie-based session stickiness when the client is running in Node.js and the server is behind an AWS ALB or another LB that uses cookie-based session stickiness.
This setup is really useful for setting up streaming between two processes across the internet that need to communicate in real-time but have to account for corporate proxies in the middle breaking any attempt at a true streaming connection.
There is a bit of a philosophical question here on whether this project wants to support this use case at all, but if you do then having some way to simulate the cookie process in the browser when using the fallback transports is a necessity.