[OASIS Issue Tracker] (AMQPBINDMAP-10) Describe a use-case where redirect might be done

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/AMQPBINDMAP-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60919#comment-60919 ] 

Steve Huston commented on AMQPBINDMAP-10:
-----------------------------------------

Last of an email chain titled " [amqp-bindmap] AMQP 1.0 Redirect with WebSockets" on the amqp-bindmap email list. Pending Rob Godfrey checking AMQP spec, the below is ok. The item on whether or not to maintain SSL/SASL on the redirect is a broader AMQP client question which can be noted in teh websockets spec and possibly later tech-noted in the AMQP TC.
---------------------------

From: John Fallows

Okay, finally had some cycles to look at this again.

Summary:

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 same scheme if unspecified on "tcp", "tls" or "sasl" connection
•	path : must begin with leading "/" when required (based on scheme)
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://network-host:port[/path], e.g. ws://example.com:80/amqp10
...and then initiate connectivity to begin the handshake.

Should we use hostname as a default hostname in the WebSocket URL if network-host is omitted? (perhaps this is a required behavior)

Also modify HTTP header definition as follows:

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.

Should the additional field names and types for both amqp:connection:redirect and amqp:link:redirect be specified in AMQP 1.0 itself?

That would allow AMQP 1.0 specification to tighten up the behavior for redirected "tls" and "sasl" connections to explicitly re-use the same transport. (if that is the desired behavior)

The AMQP 1.0 WebSocket Binding could then define additional values for the scheme, namely "ws" and "wss", as well as define how the remaining fields should be interpreted by a WebSocket client. (as described above)

Let's try to get as close as we can to a final decision on this during tomorrow's call.

cheers,
John.


> Describe a use-case where redirect might be done
> ------------------------------------------------
>
>                 Key: AMQPBINDMAP-10
>                 URL: https://issues.oasis-open.org/browse/AMQPBINDMAP-10
>             Project: OASIS Advanced Message Queuing Protocol (AMQP) Bindings and Mappings (AMQP-BINDMAP) TC
>          Issue Type: Task
>          Components: Websockets Binding
>    Affects Versions: csd01
>            Reporter: Steve Huston
>            Assignee: John Fallows
>
> At the 5/5/2015 TC meeting there was discussion of how to handle redirects. There was some desire for a use-case to be described where redirect would be needed and how it should work.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)