Thanks, Eoghan.
I can't really speak to the IP Address issue you raise -- right now
what I'm really concerned about is TLS-related information, which in
the case of the Jetty implementation, is available on off the
SSLSession. The local and peer IP addresses are available for the
asking there, too, but currently I have no need for them (though I'd
certainly be open to exposing this information to anyone downstream).
As for the aesthetic issue about whether it's easier to design a new
struct to carry this information, for each type of information, I've
submitted a patch which I think fairly effectively avoids having to
do this, and I'd argue it's no less usable or readable on the part of
the producer or consumer of this information. You'll see patterns like
ContextInfo info = message.get(TLSSessionContract.class);
java.security.cert.Certificate[] peerCerts = info.get
(TLSSessionContract.PEER_CERTIFICATES);
and off you go. This is in contrast to something like:
TLSSessionInfo info = message.get(TLSSessionInfo.class);
java.security.cert.Certificate[] peerCerts = info.getPeerCertificates();
but it has the advantage that it's slightly more future-proofed.
E.g., in the latter case, if TLSSessionInfo changes, then
implementations will fail to compile. And of course the type
(ContextInfo) has general applicability outside of my myopic needs at
present.
Of course, I'm not a committer here, so feel free to ignore the
patch. If this forum seriously feels the former approach is a
detriment to the project, I can easily retrofit the approach, but I
think that would be unfortunate. The former approach is really a lot
simpler and cleaner, IMO.
Please let me know ASAP.
Thanks,
-Fred
