Transport options/headers for server-to-server use case#534
Conversation
…Useful if you need to pass headers for example to an XHR request
…compliant with Writeable api that allows for handling back pressure
avistramer
force-pushed
the
transport-headers
branch
from
efea906 to
8bff03f
Compare
Hi @auvipy yes it is. It was opened 3.5 years ago to get this working as a Node.js client communicating with a Sockjs server that sits behind an LB (see original description). When no one responded we ended up just releasing it on our own as a separate package with the change. Recently had to make one more change to make it handle back pressure in the standard Node.js way (calling write/send to the stream returns false when it can't accept any more data and then fires a |
|
Im actually a new maintainer so willing to know its state to merge it |
|
Thanks @auvipy. I would love to see this get reviewed and merged so we can stop maintaining a separate fork with these changes included. |
|
I think the PR is missing required unit tests. can you add them please? |
avistramer
force-pushed
the
transport-headers
branch
from
3f8f0f7 to
01a34fd
Compare
|
Added some tests as requested |
auvipy
left a comment
auvipy
left a comment
There was a problem hiding this comment.
should we add additional documentation?
2 participants
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.