Safari Server Sent Event (SSE) Infinte Loop

Question

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"},
            },
        }

Answer 1

I bet that the Safari javascript console is filled with:

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

and it is very probably a protocol error. The section 8.1.2.2 of the http/2 says that

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.

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.