It would be useful to check for a valid redirect on handshake failure in the opamp-go client, and follow it to attempt to establish a websocket connection to the location specified by the redirect. This would allow more flexibility for operators who are supporting a large network of opamp servers. It is also a backwards-compatible change.
The server MAY redirect the client using a 3xx status code
[RFC2616]. Note that this step can happen together with, before,
or after the optional authentication step described above.
In https://github.com/open-telemetry/opamp-go, check for an HTTP response status >= 300 && <400. Parse the location header, and if valid, set c.url to be the URL from the location header. Then, call tryConnectOnce again.
I am happy to do the implementation work this would require, and have a changelog I can contribute in the near future.
It would be useful to check for a valid redirect on handshake failure in the
opamp-goclient, and follow it to attempt to establish a websocket connection to the location specified by the redirect. This would allow more flexibility for operators who are supporting a large network of opamp servers. It is also a backwards-compatible change.The websocket standard permits websocket servers to offer redirection to websocket clients. (See https://www.rfc-editor.org/rfc/rfc6455#section-4.2.2)
In particular,
The
gorilla/websocketlibrary does not implement this optional redirect following, but it does return a valid HTTP response when a handshake error occurs. (See https://github.com/gorilla/websocket/blob/main/client.go#L412)What I am proposing specifically:
In https://github.com/open-telemetry/opamp-go, check for an HTTP response status
>= 300 && <400. Parse the location header, and if valid, setc.urlto be the URL from the location header. Then, calltryConnectOnceagain.I am happy to do the implementation work this would require, and have a changelog I can contribute in the near future.