Updating WebSocket headers on every connection attempt
See original GitHub issueAs brought up in #autobahn
, currently a WebSocket connection gets its headers from the Factory (via. self.factory.headers
). However, a Factory may make many connections and it is desirable to have a hook to change the headers for each connection (for example, when doing re-connections).
One way would be to mutate the .headers
attribute in the Factory. This will “probably” work as there is likely only one “active” protocol instance created per-factory. However, it’s not very explicit.
@exarkun suggested: "maybe something like having WebSocketClientProtocol.onConnect
allowed to return a ConnectionRequest
(or similar) that can specify headers?
Issue Analytics
- State:
- Created 4 years ago
- Comments:24 (24 by maintainers)
Top Results From Across the Web
HTTP headers in Websockets client API - Stack Overflow
I think a good solution is to allow the WebSocket to connect without authorization, but then block and wait on the server to...
Read more >Protocol upgrade mechanism - HTTP - MDN Web Docs - Mozilla
The following headers are involved in the WebSocket upgrade process. Other than the Upgrade and Connection headers, the rest are generally ...
Read more >Adding an assembly WebSocket upgrade action - IBM
When the WebSocket connection is established, the WebSocket upgrade headers are retrieved from the API context and the payload is sent.
Read more >Websocket - Nine Nines
You must use the gun:ws_upgrade/2,3,4 function to upgrade to Websocket. This function can be called anytime after connection, so you can send HTTP...
Read more >WebSockets tutorial: How to go real-time with Node and React
While sending the regular HTTP request to establish a connection, in the request headers, the client sends *Sec-WebSocket-Key* . The server ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
That would be a neat way to make backpressure work, yeah. I just mean that oberstet’s point is good: we’d want to profile it well first to make sure that doing that doesn’t slow down “most code which is using onMessage synchronously”
Should
onConnecting
handle async / future-returning overrides? (If so, it would need to delay starting the handshake until any future resolved). For consistency, I think it probably should (i.e. in Python3 then everything can beasync def on*()
for all the various “user callbacks”).