Expose the RemoteAddr via the Connection interface #57
Conversation
server/types/connection.go
Outdated
| RemoteAddr() net.Addr | ||
|
|
||
| // Header returns the request header fields of the http request that opened the connection. | ||
| Header() http.Header |
There was a problem hiding this comment.
Do we need the Header here? The header can be already accessed in the OnConnecting callback, so this seems redundant.
There was a problem hiding this comment.
OnConnecting provides the request but at that point there is no agent information available, e.g. InstanceUid or AgentDescription, which would identify which agent is actually connecting. This information will come later in a message after the connection is established. There is also no Connection because the connection isn't established. Providing the Header on the connection will make this information available in the other callbacks and allow the server to tie this information together.
There was a problem hiding this comment.
Makes sense.
My other concern is that we may want to support gRPC in the future (see open-telemetry/opamp-spec#61) and I don't know if HTTP headers are accessible in gRPC server implementations. If they are not then we may not be able to implement this Header() function correctly.
Can you check this?
There was a problem hiding this comment.
I see. HTTP headers are generally not accessible in gRPC implementations. This presents an issue with the existing OnConnecting callback because http.Request is also not available in gRPC implementations. We can take this out if you prefer.
There was a problem hiding this comment.
Let's add RemoteAddr() in this PR and we can think about what we do with Header() separately.
There was a problem hiding this comment.
For the headers, this is how we handle them for gRPC and HTTP in OpenTelemetry Collector:
There was a problem hiding this comment.
So, looks like it is called Metadata and defined as:
// Metadata is an immutable map, meant to contain request metadata.
type Metadata struct {
data map[string][]string
}
server/types/connection.go
Outdated
| RemoteAddr() net.Addr | ||
|
|
||
| // Header returns the request header fields of the http request that opened the connection. | ||
| Header() http.Header |
There was a problem hiding this comment.
Do we need the Header here? The header can be already accessed in the OnConnecting callback, so this seems redundant.
server/types/connection.go
Outdated
| RemoteAddr() net.Addr | ||
|
|
||
| // Header returns the request header fields of the http request that opened the connection. | ||
| Header() http.Header |
There was a problem hiding this comment.
Makes sense.
My other concern is that we may want to support gRPC in the future (see open-telemetry/opamp-spec#61) and I don't know if HTTP headers are accessible in gRPC server implementations. If they are not then we may not be able to implement this Header() function correctly.
Can you check this?
andykellr
force-pushed
the
connection-remoteaddr-and-headers
branch
from
9b82cb8
to
967d5df
Compare
andykellr
changed the title
| @@ -2,13 +2,17 @@ package types | |||
|
|
|||
| import ( | |||
| "context" | |||
| "net" | |||
|
|
|||
| "github.com/open-telemetry/opamp-go/protobufs" | |||
| ) | |||
|
|
|||
| // Connection represents one OpAMP WebSocket connections. | |||
| // The implementation MUST be a comparable type so that it can be used as a map key. | |||
| type Connection interface { | |||
There was a problem hiding this comment.
@andykellr to support the use case that you have I think we also need to add net.Conn as a field. This will allow to access the TLS certificate. I believe net.Conn is accessible for WebSocket (UnderlyingConn() in ws gorilla). If you can confirm it is also accessible for gRPC connections and for plain HTTP connections then it should be OK to add it to this interface.
There was a problem hiding this comment.
@andykellr this PR looks good to me now. I will merge as is and you can address this comment in a separate PR if you need the Conn.
server/connection.go
Outdated
| @@ -16,6 +17,10 @@ type connection struct { | |||
|
|
|||
| var _ types.Connection = (*connection)(nil) | |||
|
|
|||
| func (c connection) RemoteAddr() net.Addr { | |||
| return c.RemoteAddr() | |||
There was a problem hiding this comment.
Is this recursively calling itself or I am misreading the code?
There was a problem hiding this comment.
You didn't read that wrong. I put this PR together quickly to begin discussion and it was an oversight. It clearly needs a test case as well.
This was originally proposed in a slack message in the CNCF otel-agentmanwg channel.