On 22/06/2016 22:37, Mark Hellegers wrote:
But as to the concerns about the patch:
The hostname is used in the application layer, but that does not
it an application concern. It is a network address and I see no
with storing it at the internet layer in BNetworkAddress. It
gets it anyway, we just didn't store it before. There was even
a function to retrieve the hostname in BNetworkAddres. It simply
It's an application concern because the application knows how it
be used. It should be the application's decision whether to send
the hostname for server name indication. It shouldn't depend on
I happened to construct the BNetworkAddress with a string hostname or
not. Indeed it's perfectly possible to construct a BNetworkAddress
an IP address. With this interface, it's impossible to use TLS SNI
a BNetworkAddress constructed this way.
The hostname, and how this plays a part in TLS server name
is the concern of the higher level protocol, TLS. The network layer
doesn't care about what hostname the network address sprung from; all
cares about is the IP address to connect to.
What was a fairly simple wrapper around a socket address has now
a socket address plus a hostname which may or may not be present
depending on how it was constructed. It violates the single
Also, it seems awkward to force the caller to call an extra
simply to set the hostname while BNetworkAddress seems perfectly
capable of holding that information. I would think that encourages
buggy code by applications forgetting to set it, while it is now
automatic as long as BNetworkAddress is called with a hostname.
The converse of this is that it's now forced upon the application
whether it wants it or not. An application now has to jump through
to disable SNI or if they want to use it with a socket address
resolved by other means.