Subprotocol header #363
Subprotocol header #363
Conversation
|
@daniel-abramov Are you interested in merging this? |
|
Hey, I think we've forgotten about this one, sorry (though the code looks familiar as if I have already skewed through it once). Generally, it looks ok - there is an intersection with #400 though, we'll need to check how to merge it without causing too many conflicts. UPD: I'd also need to check why no CI pipeline was run for this PR. |
|
Thanks for getting back to me. I'll update it once #400 is progressed. |
|
Hello @conorbros Here is a PR to merge shotover#1 to sync with the repo |
Change tests to merge snapview#363
There was a problem hiding this comment.
Hi @conorbros
Can you please juste made this tiny changes to passe the CI ?
FYI CI error is here : https://github.com/snapview/tungstenite-rs/actions/runs/8841412949/job/24741691622
Co-authored-by: n4n5 <[email protected]>
|
Ok, now it looks good. All tests are passed, the new code is covered with tests as well. Its time to merge. |
This is the cause of the WebSocket test failures: snapview/tungstenite-rs#363 In short, tungstenite in 0.22.0 started to validate that if you requested a particular protocol, the server actually declared support for that protocol. In tests, our clients request the `graphql-transport-ws` protocol, but the mock server doesn't declare support for it, so the client now fails to connect. This is worth calling out in the 2.0 migration guide, because it's plausible that a misbehaving subgraph would work in 1.x, but no longer work in 2.0.
Add client-side handling for subprotocol header during handshake.