If the initial URL for the opamp client points to a resource that returns a redirect (HTTP 301 or 302), the underlying okhttp client will turn around and issue a GET request to the redirected Location. This is not normal expected behavior, but can happen if a resource moves or if the client is misconfigured.

See square/okhttp#6627 for additional context about this behavior.
You can reproduce this by setting the opamp endpoint url to http://cisco.com/

The end result is that the connection is considered successful and the callback onConnect() is called...which appears as success...even though we are not connected to a valid opamp server.

What can we do about it? I'm not sure yet, but there are a couple options:

• maybe we should always fail in the event that a redirect is returned to the POST?
• ...or maybe add an okhttp interceptor that somehow detects this 301/302 response to a POST and ensures that the following requests are also POST (maybe all requests should always be POST?)
• ...or maybe (also?) wait until after the response is successfully decoded as protobuf before determining connection success.