IE 8 和 IE 9

Internet Explorer 8 和 9 仍然在使用。它们是拥有 SockJS 的一个重要原因。本节涵盖了关于在这些浏览器中运行的重要考虑。

SockJS 客户端通过使用微软的 XDomainRequest 在 IE 8 和 9 中支持 Ajax/XHR 流。这可以跨域工作，但不支持发送 cookies。对于 Java 应用程序来说，Cookies 通常是必不可少的。然而，由于 SockJS 客户端可以与许多服务器类型（不仅仅是 Java 的）一起使用，它需要知道 cookies 是否重要。如果是的话，SockJS 客户端更倾向于使用 Ajax/XHR 进行流式传输。否则，它依赖于基于 iframe 的技术。

来自 SockJS 客户端的第一个 /info请求是一个信息请求，它可以影响客户端对传输的选择。其中一个细节是服务器应用程序是否依赖 cookie（例如，为了验证目的或用粘性会话进行集群）。Spring 的 SockJS 支持包括一个叫做 sessionCookieNeeded 的属性。它默认是启用的，因为大多数 Java 应用都依赖于 JSESSIONID cookie。如果你的应用程序不需要它，你可以关闭这个选项，然后 SockJS 客户端应该在 IE 8 和 9 中选择 xdr-streaming。

如果你确实使用了基于 iframe 的传输，请记住，浏览器可以通过将 HTTP 响应头 X-Frame-Options设置为 DENY、SAMEORIGIN 或 ALLOW-FROM <origin>来指示阻止在特定页面上使用 IFrame。这是用来防止点击劫持的。

:::info Spring Security 3.2+ 提供了对每个响应设置 X-Frame-Options 的支持。默认情况下，Spring Security 的 Java 配置将其设置为 DENY。在 3.2 中，Spring Security 的 XML 命名空间默认不设置该头，但可以配置为这样做。在未来，它可能会默认设置它。

关于如何配置 X-Frame-Options 头的设置，请参阅 Spring Security 文档的 Default Security Headers。你也可以参见 SEC-2501 以了解更多背景。 :::

如果你的应用程序添加了 X-Frame-Options 响应头（应该如此！），并且依赖于基于 iframe 的传输，你需要将头的值设置为 SAMEORIGIN 或 ALLOW-FROM <origin>。Spring SockJS 支持也需要知道 SockJS 客户端的位置，因为它是从 iframe 中加载的。默认情况下，iframe 被设置为从 CDN 位置下载 SockJS 客户端。把这个选项配置为使用与应用程序相同来源的 URL 是一个好主意。

下面的例子显示了如何在 Java 配置中这样做：

@Configuration
@EnableWebSocketMessageBroker
public class WebSocketConfig implements WebSocketMessageBrokerConfigurer {
    @Override
    public void registerStompEndpoints(StompEndpointRegistry registry) {
        registry.addEndpoint("/portfolio").withSockJS()
                .setClientLibraryUrl("http://localhost:8080/myapp/js/sockjs-client.js");
    }
    // ...
}

XML命名空间通过 <websocket:sockjs>元素提供了一个类似的选项。

:::info 在最初的开发过程中，请务必启用 SockJS 客户端开发模式，以防止浏览器缓存 SockJS 请求（如 iframe），否则会被缓存。关于如何启用它的细节，请参见 SockJS 客户端页面。 :::