I am having issues with server-send events (SSE) in Safari 9 and Safari 10. The SSE connection opens, immediately closes and then reconnects in an infinite loop.
This is the client side code:
var events = new EventSource("/stream/events")
These are the http response headers:
> 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
Some additional notes:
- I tested in Chrome and Firefox and cannot repeat
- I tested in Safari without https and cannot repeat
- I tested in Safari with https and can repeat
- The https certificates are auto-generated using Lets Encrypt
- The backend server is written in Go and uses http/2 by default
The fact that I can only repeat in Safari with https is interesting. I am therefore wondering if there are any known issues with SSE and https, or if there is anything else I might be misconfiguring or missing here.
EDIT
I have isolated the problem and found a correlation to the protocol. When the http2 protocol is enabled, I am able to reproduce this issue. When http2 is disabled on the server, I am no longer able to reproduce this problem.
I used the following server patch to verify:
--- 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"},
},
}
I bet that the Safari javascript console is filled with:
and it is very probably a protocol error. The section 8.1.2.2 of the http/2 says that
I cannot ensure that this is your problem, since I don't see the HTTP headers of your http/2 attempt, but many http/2 implementations made the choice of still sending
Connection: Keep-Alive
headers while several user agents, including Safari and curl, decided to be strict on the matter.UPDATE
I should add that the faulty header, most probably the standard `Connection: keep-alive' one, can have been set by any server side component (typically the SSE server-side component of the application), not the container itself. I bet that containers should filter it in http/2.