javascript - Safari 服务器发送事件 (SSE) 无限循环

Question

我在 Safari 9 和 Safari 10 中遇到服务器发送事件 (SSE) 问题。SSE 连接打开，立即关闭，然后在无限循环中重新连接。

这是客户端代码:

var events = new EventSource("/stream/events")

这些是 http 响应 header :

> GET /stream/events HTTP/1.1
> User-Agent: curl/7.43.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Access-Control-Allow-Origin: *
< Cache-Control: no-cache
< Connection: keep-alive
< Content-Type: text/event-stream
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Last-Modified: Tue, 19 Sep 2017 05:28:22 GMT
< Strict-Transport-Security: max-age=31536000
< X-Accel-Buffering: no
< X-Content-Type-Options: nosniff
< X-Frame-Options: DENY
< X-Xss-Protection: 1; mode=block
< Date: Tue, 19 Sep 2017 05:28:22 GMT
< Transfer-Encoding: chunked

一些附加说明:

我在 Chrome 和 Firefox 中测试过，无法重复

我在 Safari 中测试过 没有 https 并且不能重复

我在 Safari 中测试过 与 https 并且可以重复

https 证书是使用 Lets Encrypt

自动生成的。

后端服务器是用 Go 编写的，默认使用 http/2

我只能在 Safari 中使用 https 重复这一事实很有趣。因此，我想知道 SSE 和 https 是否存在任何已知问题，或者我可能在此处配置错误或遗漏了其他任何问题。

编辑

我已经隔离了问题并发现了与协议(protocol)的相关性。启用 http2 协议(protocol)后，我能够重现此问题。在服务器上禁用 http2 时，我不再能够重现此问题。

我使用以下服务器补丁进行验证:

--- before.go   2017-09-19 13:31:45.668891000 -0400
+++ after.go    2017-09-19 13:31:55.100891000 -0400
@@ -2,6 +2,6 @@
            Addr: ":443",
            TLSConfig: &tls.Config{
                GetCertificate: manager.GetCertificate,
-               NextProtos:     []string{"h2", "http/1.1"},
+               NextProtos:     []string{"http/1.1"},
            },
        }

Answer 1

我敢打赌 Safari javascript 控制台充满了:

[Error] Failed to load resource: The operation couldnt be completed. Protocol error

这很可能是一个协议(protocol)错误。 section 8.1.2.2 http/2 的说

An endpoint MUST NOT generate an HTTP/2 message containing connection-specific header fields; any message containing connection-specific header fields MUST be treated as malformed.

我无法确定这是您的问题，因为我没有看到您的 http/2 尝试的 HTTP header ，但是许多 http/2 实现选择仍然发送 Connection: Keep-Alive header ，而包括 Safari 和 curl 在内的几个用户代理决定对此事采取严格的态度。
更新
我应该补充一点，错误的 header ，很可能是标准的“连接:保持事件”之一，可以由任何服务器端组件(通常是应用程序的 SSE 服务器端组件)设置，而不是容器本身。我打赌容器应该在 http/2 中过滤它。