Expose SslConfig through ConnectionInfo
#2150
Conversation
| * @return The {@link SslConfig} if SSL/TLS is configured, or {@code null} otherwise. | ||
| */ | ||
| @Nullable | ||
| default SslConfig sslConfig() { // FIXME: 0.43 - consider removing default impl |
There was a problem hiding this comment.
Added more reviewers for visibility of this message:
WDYT about exposing sslConfig() through ExecutionContext instead of ConnectionInfo? That way it will be automatically visible through client.executionContext() and serverContext.executionContext() too.
There was a problem hiding this comment.
We discussed this offline, and agreed that its more relevant as part of the ConnectionInfo.
There was a problem hiding this comment.
For visibility: client is an abstraction that does not know about the actual connections. There are implementations of the client (multi-address client) that can talk to HTTP and HTTPS targets. Therefore, having SslConfig at the client level does not make sense.
We can add serverContext.sslConfig() later, if we have a use-case for that. For now, will just keep it at ConnectionInfo.
Motivation: `SSLSession` represents the result of SSL negotiation. However, it's useful to know what `SslConfig` was used to establish the session for observability or runtime checks. Modifications: - Add `ConnectionInfo#sslConfig()` method; - Propagate `SslConfig` to all `ConnectionInfo` implementations; - Adjust tests; Result: Users have access to `SslConfig` from service or connection factory/filter.
idelpivnitskiy
force-pushed
the
ssl-config
branch
from
96f0a61 to
b802c8c
Compare
Motivation:
SSLSessionrepresents the result of SSL negotiation. However, it'suseful to know what
SslConfigwas used to establish the session forobservability or runtime checks.
Modifications:
ConnectionInfo#sslConfig()method;SslConfigto allConnectionInfoimplementations;Result:
Users have access to
SslConfigfrom service or connectionfactory/filter.