You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be great if we could expose an option (perhaps in ZioHttpServerOptions?) to allow customizing zio-http's WebsocketConfig prior to constructing the response. This would allow us to modify the subprotocols in the config depending on some request params, e.g., headers.
In the case of Caliban, that would be defining the subprotocols based on the sec-websocket-protocol header. We currently have a workaround where we provide a default config that users need to use when initializing the server, but if users skip that step then their GraphQL Subscriptions won't work. This unfortunately degrades UX and could break deployments in production if the WS endpoints are not individually tested at the HTTP layer if the custom config is removed.
I'm happy to submit a PR and add that option in ZioHttpServerOptions, although I thought to open an issue first in case you think there's a better approach to resolving this
The text was updated successfully, but these errors were encountered:
Following up on this comment.
As mentioned in the comment, zio-http 3.0.0-RC3 added back the ability to provide a custom websocket config when handling a request.
It would be great if we could expose an option (perhaps in
ZioHttpServerOptions
?) to allow customizing zio-http'sWebsocketConfig
prior to constructing the response. This would allow us to modify the subprotocols in the config depending on some request params, e.g., headers.In the case of Caliban, that would be defining the subprotocols based on the
sec-websocket-protocol
header. We currently have a workaround where we provide a default config that users need to use when initializing the server, but if users skip that step then their GraphQL Subscriptions won't work. This unfortunately degrades UX and could break deployments in production if the WS endpoints are not individually tested at the HTTP layer if the custom config is removed.I'm happy to submit a PR and add that option in
ZioHttpServerOptions
, although I thought to open an issue first in case you think there's a better approach to resolving thisThe text was updated successfully, but these errors were encountered: