[wildfly-dev] HTTP Upgrade for AS8 Management

[David M. Lloyd]

Yes.

On 06/02/2014 11:46 AM, Darran Lofthouse wrote:
> So just to be clear, you believe it should be 'remote' not 'remoting'?
>
> Regards,
> Darran Lofthouse.
>
>
> On 02/06/14 17:42, David M. Lloyd wrote:
>> 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).
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
- DML