I think this issue is related to a couple of others: PROTON-161,
PROTON-90, and PROTON-136, and to some extent PROTON-164 (specifically the portion pertaining to redirect).
The spec has the following language regarding the hostname field:
"The name of the host (either fully qualified or relative) to which the sending peer
is connecting. It is not mandatory to provide the hostname. If no hostname is provided
the receiving peer SHOULD select a default based on its own configuration. This field
can be used by AMQP proxies to determine the correct back-end service to connect
the client to.
This field MAY already have been specified by the <xref name="sasl-init"/> frame, if a
SASL layer is used, or, the server name indication extension as described in
RFC-4366, if a TLS layer is used, in which case this field SHOULD be null or contain
the same value. It is undefined what a different value to that already specified
Note in particular the relationship between the TLS hostname and this field.
PROTON-90 have identified the need to somehow specify a name to match against the TLS certificate. I think there may be a requirement implicit in PROTON-136 to key the session cache off of something meaningful to the TLS layer, and of course we have this Jira. It sounds to me like these all fall under the general problem that the "TLS endpoint" needs to be able to be independent from the "TCP endpoint", although for obvious reasons it's desirable to make it easy (i.e. default them) to be the same.
From what I can tell, it seems like the open.hostname field, the session key used for
PROTON-136, and the name we match against the TLS certificate all should come from a single source. Right now that source is the message address. Assuming that is the right source for that info we need to specify exactly how to transform the address into this "TLS hostname" thing. This relates to PROTON-163, as that is pointing out a specific case where we are transforming incorrectly, but it would also be good to know how to handle other kinds of URLs as the URL syntax allows lots of random cruft in there and I don't know offhand what is supposed to be part of this canonical TLS hostname thingy and what isn't, e.g. if you do amqp://host:port/blah, is the port part of it or not? I'm guessing there's some possibly authoritative info out there we can crib from on what browsers do as this is essentially the same problem as transforming the typed-in URL into the HTTP "Host" header.
Now as for this JIRA in particular, I think we need to understand the overall resolution process that messenger goes through when resolving the TCP connection info for a given message address, and this needs to somehow account for redirects as mentioned in
PROTON-164. Right now messenger will do a DNS lookup on the host portion of the message address in order to determine the TCP endpoint, however it only does this the first time it encounters a message to a given address. All subsequent messages to the same address will get sent down the same connection that was established by the first message for as long as that connection survives. Now assuming we transparently handle redirects as simply a further step in the resolution process, then I would expect this scenario to extend pretty well. On the first message we'd do the DNS lookup, connect to a redirector, and then establish a permanent connection and send all subsequent messages there. What's not clear to me though is how this would interact with option (1). If we're specifying a network address to connect to on a per message basis, then what happens if we have already have an existing connection for the address specified in this message, and this existing connection doesn't match the supplied network address? If we use the existing connection then I would say we aren't really specifying network connectivity on a per message basis, we're actually just short-circuiting/overriding the resolution process, i.e. this is equivalent to simply configuring a set of aliases for the messenger, e.g. when you see address "foo", make your TCP connection to "bar". On the other hand if we don't use the existing connection we could end up with some pathological behaviour if you point your message to a redirector since we would end up making a new connection for every single message we send.
Apologies for the long and rambling post, I probably shouldn't have tried to tackle this one so late. I guess I'll just wrap up by asking A) does any of the above make sense, and B) do you have any more info on the overall scenario you're trying to support, and C) is it worth investigating some kind of option (3) along the lines of the aliasing mentioned above?