Issue: SPR-12956

Issue: SPR-12955

This change adds support for broadcasting messages with unresolved
user destinations so that other servers can try to resolve it.
That enables sending messages to users who may be connected to a
different server.

Issue: SPR-11620

Issue: SPR-10954

This commit introduces support for CORS in Spring Framework.

Cross-origin resource sharing (CORS) is a mechanism that allows
many resources (e.g. fonts, JavaScript, etc.) on a web page to
be requested from another domain outside the domain from which
the resource originated. It is defined by the CORS W3C
recommandation (http://www.w3.org/TR/cors/).

A new annotation @CrossOrigin allows to enable CORS support
on Controller type or method level. By default all origins
("*") are allowed.

@RestController
public class SampleController {

	@CrossOrigin
	@RequestMapping("/foo")
	public String foo() {
		// ...
	}
}

Various @CrossOrigin attributes allow to customize the CORS configuration.

@RestController
public class SampleController {

	@CrossOrigin(origin = { "http://site1.com", "http://site2.com" },
				 allowedHeaders = { "header1", "header2" },
				 exposedHeaders = { "header1", "header2" },
				 method = RequestMethod.DELETE,
				 maxAge = 123, allowCredentials = "true")
	@RequestMapping(value = "/foo", method = { RequestMethod.GET, RequestMethod.POST} )
	public String foo() {
		// ...
	}
}

A CorsConfigurationSource interface can be implemented by HTTP request
handlers that want to support CORS by providing a CorsConfiguration
that will be detected at AbstractHandlerMapping level. See for
example ResourceHttpRequestHandler that implements this interface.

Global CORS configuration should be supported through ControllerAdvice
(with type level @CrossOrigin annotated class or class implementing
CorsConfigurationSource), or with XML namespace and JavaConfig
configuration, but this is not implemented yet.

Issue: SPR-9278

Prior to this commit, the `client-library-url` XML attribute was not
effective in the MVC namespace, leaving the default value configured:

```xml
<websocket:sockjs client-library-url="/js/sockjs.js" />
```

This commit fixes the sockjs namespace handler and makes sure that this
attribute is configured on the `SockJsService` Bean to be created.

Issue: SPR-12874

Issue: SPR-12812

This change adds support for global @MessageExceptionHandler methods
with STOMP over WebSocket messages. Such methods can be added to
@ControllerAdvice annotated components, much like @ExceptionHandler
methods for Spring MVC.

Issue: SPR-12696

WebSocketStompClient can be used with any implementation of
org.springframework.web.socket.client.WebSocketClient, which includes
org.springframework.web.socket.sockjs.client.SockJsClient.

Reactor11TcpStompClient can be used with reactor-net and provides STOMP
over TCP. It's also possible to adapt other WebSocket and TCP client
libraries (see StompClientSupport for more details).

For example usage see WebSocketStompClientIntegrationTests.

Issue: SPR-11588

Issue: SPR-12727

This commit adds support for a same origin check that compares
Origin header to Host header. It also changes the default setting
from all origins allowed to only same origin allowed.

Issues: SPR-12697, SPR-12685

Add support for annotation-based event listeners. Enabled automatically
when using Java configuration or can be enabled explicitly via the
regular <context:annotation-driven/> XML element. Detect methods of
managed beans annotated with @EventListener, either directly or through
a meta-annotation.

Annotated methods must define the event type they listen to as a single
parameter argument. Events are automatically filtered out according to
the method signature. When additional runtime filtering is required, one
can specify the `condition` attribute of the annotation that defines a
SpEL expression that should match to actually invoke the method for a
particular event. The root context exposes the actual `event`
(`#root.event`) and method arguments (`#root.args`). Individual method
arguments are also exposed via either the `a` or `p` alias (`#a0` refers
to the first method argument). Finally, methods arguments are exposed via
their names if that information can be discovered.

Events can be either an ApplicationEvent or any arbitrary payload. Such
payload is wrapped automatically in a PayloadApplicationEvent and managed
explicitly internally. As a result, users can now publish and listen
for arbitrary objects.

If an annotated method has a return value, an non null result is actually
published as a new event, something like:

@EventListener
public FooEvent handle(BarEvent event) { ... }

Events can be handled in an aynchronous manner by adding `@Async` to the
event method declaration and enabling such infrastructure. Events can
also be ordered by adding an `@order` annotation to the event method.

Issue: SPR-11622

This commit introduces the following changes:
 - Requests without Origin header are not rejected anymore
 - Disable Iframe when allowedOrigins is not empty and not equals to *
 - The Iframe is not cached anymore in order to have a reliable origin check
 - allowedOrigins must not be null or empty
 - allowedOrigins format is now validated (should be * or start by http(s)://)

Issue: SPR-12660

A logical follow-up on commit 43d937, this change also removes (or
rather deprecates for now) writePrelude that is only of concern to
streaming SockJS session implementations.

Issue: SPR-12427

This change removes the need for the isStreaming field from the base
class AbstractHttpSockJsSession. This field was used to account for
differences between polling vs streaming SockJS sessions without having
to expose to sub-classes private fields that are otherwise protected
from concurrent access by the base class. The change manages to delegate
to sub-classes without providing direct access to protected fields.

Issue: SPR-12427

This change designates Jetty SockJS integration tests to run as part of
the "performance", but not the main "publication", CI build due to
recurring low-level failures suspected to be Jetty issues, e.g.
"java.io.IOException: Cannot append to finished buffer" or
"java.io.IOException: Out of order Continuation frame encountered".

The tests will still run at once a day with the performance build but
should not fail the main build with false negatives. Also note that
an Undertow variant of the exact same tests, which hasn't been failing,
will continue to run as part of the main build.

The following two refinements have been added:
1) SockJS doesn't support binary messages so don't even try
2) don't bother if payload.length == 0

Issue: SPR-12475

Issue: SPR-12516

Issue: SPR-12497

Prior to this change, duplicate SubProtocolHandlers could be registered
when configuring STOMP with several registrations:

    public void registerStompEndpoints
          (final StompEndpointRegistry registry) {
      this.endpointRegistry.addEndpoint("/stompOverWebSocket");
      this.endpointRegistry.addEndpoint("/stompOverSockJS").withSockJS();
    }

This commit registers sub-protocols in a Set instead of a list (see
SubProtocolWebSocketHandler), thus fixing the issue.

Issue: SPR-12403

Issues: SPR-12283

This commit introduces a new OriginHandshakeInterceptor. It filters
Origin header value against a list of allowed origins.

AbstractSockJsService as been modified to:
 - Reject CORS requests with forbidden origins
 - Disable transport types that does not support CORS when an origin
   check is required
 - Use the Origin request header value instead of "*" for
   Access-Control-Allow-Origin response header value
   (mandatory when  Access-Control-Allow-Credentials=true)
 - Return CORS header only if the request contains an Origin header

It is possible to configure easily this behavior thanks to JavaConfig API
WebSocketHandlerRegistration#addAllowedOrigins(String...) and
StompWebSocketEndpointRegistration#addAllowedOrigins(String...).
It is also possible to configure it using the websocket XML namespace.

Please notice that this commit does not change the default behavior:
cross origin requests are still enabled by default.

Issues: SPR-12226

This change adds a ChannelInterceptor that flips the immutable flag on
messages being sent. This allows components sending messages to leave
the message mutable for interceptors to further apply modifications
before the message is sent (and exposed to concurrency).

The interceptor is automatically added with the STOMP/WebSocket Java
and XML config and the StompSubProtocolHandler leaves parsed incoming
messages mutable so they can be further modified before being sent.

Issue: SPR-12321

Issue: SPR-12340

Use explicit flag whether to copy all attributes.

The WebSocketMessageBroker config now allows wrapping the
SubProtocolWebSocketHandler to enable advanced use cases that may
require access to the underlying WebSocketSession.

Issue: SPR-12314

Issue: SPR-12314

This change adds a new XhrTransport for the SockJs client
implementation. This transport is based on `UndertowClient`,
Undertow's HTTP client.

Note that this transport can be customized with an OptionMap that is
used by the Xnio worker backing the I/O communications (see
http://xnio.jboss.org).

Implementation tested with undertow 1.0.36, 1.1.0.RC3, 1.2.0.Beta1.

Issue: SPR-12008

This change adds a "Vary: Origin" HTTP response header for /info and
/iframe SockJS endpoints.
This is preventing proxies and browsers from caching a response and
reusing it for an invalid Origin.

Reference: https://groups.google.com/forum/#!topic/sockjs/svsLWRorSis

Issue: SPR-12310

TextMessage.toString() does not throw StringIndexOutOfBoundsException for payload with multibyte characters

Issue: SPR-12307