[wildfly-dev] HTTP Upgrade for AS8 Management

[David M. Lloyd]

On 03/28/2013 05:15 AM, Stuart Douglas wrote:
> - ModelControllerClient.Factory.create() now allows you to specify a
> protocol, which can be either remote, http or https.
>
> - Remote JMX will now require a service:jmx:http(s)-remoting-jmx:// URL
> rather than the current service:jmx:remoting-jmx://

Unfortunately I missed-slash-bungled this way back when, but we need to 
sort out our URI schemes.

When we have multi-layer protocol going on, the URI scheme we should use 
is like this:

   outer+middle+inner://

where "outer" is the outermost protocol (e.g. "remote"), and "inner" is 
the innermost (not counting layer 3 and lower *unless* that figures 
directly in to the URI scheme; an example of this sub-case is 
"stratum+tcp" vs "stratum+udp").

So we *should* have:

   remote://           Direct Remoting-protocol connection
   remote+http://      Remoting over HTTP upgrade
   remote+https://     Remoting over HTTPS upgrade

And (if these are even really needed; I think we dropped this 
distinction though maybe I'm wrong):

   jmx+remote://       JMX over Remoting
   jmx+remote+http://  JMX over Remoting over HTTP
   jmx+remote+https:// JMX over Remoting over HTTPS

The most common "de facto" function of hyphenation in a URI scheme is to 
be a separator for a two-word protocol, like "view-source" or "ms-help" 
etc.  The most common "de facto" function of using "+" is as I've 
described above, perhaps made most popular by Subversion's use.

You may be wondering: Why not apply this to every single protocol we 
have?  And/or every single protocol in existence?  I think this goes 
beyond practicality - the point is to be unambiguous and consistent, and 
also align on the correct "remote" scheme name (we have a mix of 
"remote" and "remoting" today which is kind of confusing).

Fixing this is not really a top priority obviously, but I would like to 
eventually unify our configuration on these scheme names (still 
supporting the old scheme names for compatibility of course).
-- 
- DML