Closed jcbain closed 3 months ago
Thanks for reporting! Would you like to send a Pull Request to address this issue? Remember to add unit tests.
Thanks for reporting! Would you like to send a Pull Request to address this issue? Remember to add unit tests.
Yeah, I can do that!
Sorry for the silence. After further review, it appears that this functionality does work with dynamic websocket proxying endpoints but only for the upstream
option and not the wsUpstream
. I'm happy to create a PR for allowing dynamic endpoints using the similar pattern of an empty upstream
for an empty wsUpstream
for perhaps more clarity of usage.
I'm also, personally, okay with this being closed since there is a workaround.
a PR would be great.
Prerequisites
🚀 Feature Proposal
It would be nice to allow for dynamic upstreams when forwarding on websocket upgraded requests much in the same way that you can specify a
getUpstream
function to yourreplyOptions
to pass some logic to determine an http upstream. However, leaving thewsUpstream
property as an empty string results in the following error:It would be nice if this could be avoided when a
getUpstream
is supplied for an emptywsUpstream
option.Motivation
No response
Example
For example, it would be nice to register a websocket proxying mechanism like so