>
So, one possibility then would be to define some additional fields for both the amqp:connection:redirect
>
and amqp:link:redirect types, mostly useful for our WebSockets case but potentially generic for any
>
URL-based AMQP 1.0 transport.
>
> *
scheme : interpreted as "tcp" if unspecified
> *
path : interpreted as empty if unspecified
>
>
In combination with existing fields in those types...
>
> *
hostname : the hostname of the container
> *
network-host : DNS hostname or IP address of machine hosting the container
> *
port : the port number on the machine hosting the container
> *
address : the address of the terminus at the container (amqp:link:redirect only)
>
...we can construct a URL to follow the AMQP 1.0 redirect as follows:
>
> *
scheme://hostname:port[path], e.g. ws://example.com:80/amqp10
>
>
...and then initiate network connectivity to "network-host" to begin the handshake.
So, I think the correct interpretation is scheme://network-host:port[/path]
That is in the URL the network-host should be used (rather than the AMQP container “hostname”, and the path does need a mandatory leading slash.
>
>
However, browser environments do not allow such direct access to the network for sandboxed security reasons.
>
The network-host would have no meaning in that environment because the physical connectivity would typically
>
be determined by resolving the "hostname" in the WebSocket URL via DNS (in other scenarios a proxy may be
>
the first physical hop).
>
> Note: using the term "scheme" here rather than protocol since "wss" is not really a protocol, it is a scheme
>
that unpacks to ws protocol over http protocol (during-handshake) over tls protocol, etc. The
>
URL Wikipedia article makes the same point stating that the "mailto" URL scheme is not a protocol.
>
Perhaps we should also consider using "network-host" in the constructed WebSocket URL for redirect?
>
> *
scheme://network-host:port[path], e.g. ws://example.com:80/amqp10
>
>
This may be more consistent with the TCP approach, given that there appears to be no requirement for the DNS
>
name of the machine hosting the container to match the logical AMQP 1.0 hostname used in OPEN.
>
> *
tcp://network-host:port, e.g. tcp://amqp.internal.net:5672
>
>
This distinction between hostname and network-host is a key point that will potentially influence how we
>
proceed on the OPEN frame.
In general the idea is that hostname and network-host should be the same. Allowing hostname to be set separately does potentially allow for the case where
the proxy has a different address to the actual AMQP service (or simply where the AMQP service offers many more “virtual hosts” than DNS names :) ).
> Yes, this is a definite possibility, similar in spirit to the HTTP Host header that travels across any number
of TCP intermediaries
> before arriving at the target server HTTP endpoint.
> Perhaps something like "location" with value equivalent to "ws://example.com/amqp10"
would be a reasonable connection property to add in the OPEN frame from the client?
AMQP already carries a “host” in the open frame which sort of fulfils this purpose, however it does
not carry the protocol being used to connect (i.e. it would say only “example.com” or maybe “example.com/amqp10”)
– actually do we talk in the binding document about what value should be placed in the open frame here? My suggestion is that we additionally carry some property which conveys the protocol over which the initial connection was made.
>
In the binding document, we currently specify that the HTTP Host header in the WebSocket handshake should
>
identify the hostname of the AMQP 1.0 container and should match the hostname in the OPEN frame sent later
>
over the same connection after the WebSocket handshake is completed.
>
IMHO, the (optional) hostname concept in the OPEN frame is part of the AMQP 1.0 domain, whereas the HTTP
>
hostname in a WebSockets URL is part of the AMQP 1.0 transport and is not always required to match.
It’s certainly not required to match – I’m not sure what that sentence adds to the binding document, the details of websockets as a transport should not really
be relevant here
>
This interpretation seems consistent with the existing TCP semantics. For example, after following an
>
amqp:connection:redirect using TCP transport, the OPEN hostname may no longer match the DNS name of the
>
physical connection to network-host.
>
IMHO, there is an issue with the binding document in section 2.1 Opening a WebSocket Connection,
>
specifically regarding the interpretation of the HTTP Host header.
>
Host HTTP header : Identifies the hostname of the AMQP container. The value provided here SHOULD match that provided
later in the
>
hostname field of the open frame, and during SASL negotiation (if used).
>
The AMQP 1.0 OPEN frame should own identification of the AMQP 1.0 hostname when clients connect over
>
WebSockets just as for TCP, but the current wording of the binding specification seems to imply that
>
the HTTP Host header dominates when the HTTP Host header and AMQP 1.0 OPEN hostname field differ.
>
For example, if the AMQP 1.0 OPEN hostname is omitted from a WebSockets client, the same semantics as
>
TCP should be followed, namely "if no hostname is provided, the receiving peer SHOULD select a default
>
based on its own configuration" (AMQP 1.0 specification, section 2.7.1). Otherwise, there appears to
>
be no natural way to pick up the AMQP 1.0 broker default hostname when accessed by clients over
>
WebSockets.
>
If we intend to have the AMQP OPEN frame hostname field dominate, then perhaps we just need to modify
>
the wording:
>
Host HTTP header : this value MAY be used to identify the hostname of the AMQP container if the hostname field is
omitted from
>
the open frame during the AMQP handshake.
>
...or words to that effect. :-)
Agreed – I think this is a better definition
> One thing that is still not quite clear to me in this approach is how an AMQP 1.0 broker would discover the appropriate
target
> WebSocket URL to redirect the client if the AMQP 1.0 broker is not directly already aware of WebSocket-based connectivity.
Yes – this could only work if the broker was aware that there is the possibility of
intermediaries, or in general allows full configuration of the properties that get put in the error map for redirect. At some level all values in the redirect map must have come from user configuration – what we are implying here is that broker vendors should
allow for the addition of properties to this configuration that they themselves do not understand.
>
An AMQP 1.0 broker configured for direct client access over WebSockets (without any tcp-to-websockets
>
intermediaries) would already be in a position to issue amqp:connection:redirect and amqp:link:redirect
>
frames modified as discussed above.
>
An AMQP 1.0 broker configured for direct client access over TCP, with WebSocket access via tcp-to-websockets
>
intermediaries, would require additional configuration to be in a position to issue amqp:connection:redirect
>
and amqp:link:redirect frames modified as discussed above.
>
Such brokers would also need to determine that a client could (only?) follow such a WebSocket-based redirect.
>
An AMQP 1.0 broker configured for direct client access over TCP, with WebSocket access via tcp-to-websockets
>
intermediaries that also understand AMQP 1.0 protocol, would not require additional configuration because the
>
intermediary could re-write amqp:connection:redirect and amqp:link:redirect frames modified accordingly as
>
discussed above.
>
Btw, what is the expected behavior of an AMQP 1.0 TCP client that receives a redirect after connecting via
>
SASL? Should the client use SASL for the redirected connection or not? Similar question for how to know
>
whether to use TLS when following the redirect.
I think the expectation is that it will attempt to establish the same level of encryption and use the same identity as with the initial connection. This is
never made explicit though.
As far as I can tell, we still have outstanding the definition of some connection property which identifies the scheme/protocol over which the AMQP endpoint
sending an open believes it is communicating (so a websocket client would say ws and a broker sending (potentially unknowingly) through an intermediary would say “tcp”… what else is there left to define?
Cheers,
Rob