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
Currently we only support a RelayUrl with a toplevel domain name: https://example.com/. Internally this will results in several routes being served, like https://example.com/relay etc.
Perhaps we should consider allowing it to be hosted on any custom path prefix as well: https://example.com/path/prefix/ so that the routes served are "mounted" at this location: https://example.com/path/prefix/relay etc.
This could make sense in some deployments where the same domain wants to host other resources.
The text was updated successfully, but these errors were encountered:
Would be nice to document all the paths that should be proxied. I proxy /relay as a websocket, but there is also /generate_204 (which, well, generates error 204), /relay/probe (which seems to be unused) and legacy /derp and /derp/probe.
/relay/probe is used by the https probe which is still stuck in a branch somewhere. Given I'm inclined to change the path of it anyway there's no point to proxy it for now. And even if it existed it might be better to configure the proxy server to respond to it directly because the latency of the response on that path matters.
Currently we only support a
RelayUrl
with a toplevel domain name:https://example.com/
. Internally this will results in several routes being served, likehttps://example.com/relay
etc.Perhaps we should consider allowing it to be hosted on any custom path prefix as well:
https://example.com/path/prefix/
so that the routes served are "mounted" at this location:https://example.com/path/prefix/relay
etc.This could make sense in some deployments where the same domain wants to host other resources.
The text was updated successfully, but these errors were encountered: