Artemis client doesn't correctly enclose IPv6 address when sending HTTP upgrade packet.

Customer impact: Customer uses IPv6 and has EAP servers with messaging behind loadbalancer (Undertow reverse proxy). Messaging clients can not connect to worker servers behind loadbalancer

According to RFC2732 , section 2. Literal IPv6 Address Format in URL's Syntax and HTTP header field definition specification, correct request URL should be enclosed like following one: http://[fe80::56ee:75ff:fe47:c83e]

Following code snippet creates request for URL http://fe80::56ee:75ff:fe47:c83e. According to specification this is not valid URL.

HashMap<String, Object> map = new HashMap<String, Object>();
map.put("host", "fe80::56ee:75ff:fe47:c83e");
map.put("port", "8080");
map.put(TransportConstants.HTTP_UPGRADE_ENABLED_PROP_NAME, true);

TransportConfiguration transportConfiguration = new TransportConfiguration(NettyConnectorFactory.class.getName(), map);
ConnectionFactory cf = ActiveMQJMSClient.createConnectionFactoryWithoutHA(JMSFactoryType.CF, transportConfiguration);
 connection = cf.createConnection();

Configuration above should be valid. Artemis client should detect IPv6 address and enclose it, so it conforms to specification.

Current implementation works fine when client connects to EAP. However it may cause problems when Artemis client connects to proxy which expects IPv6 address correctly enclosed. This causes problems when there is a load balancer configured as an Undertow reverse proxy. Loadbalancer can not parse hostname and port, because it expects correctly enclosed URL.