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.
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
GETrequest 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: