SSE in Go breaks twice before your handler runs: an illegal header, then a 30-second timeout

The two failures produce the same error string, which is why the second one needed two rounds. The shared server package sets its WriteTimeout to 30 seconds, and the middleware that cancels the request context is also set to 30 seconds ^[9]. The effective deadline is 30 seconds whichever one you remove first, so the browser reports the same reconnect loop at the same second ^[1]. A partial fix is indistinguishable from no fix, which is an expensive property for a config bug to have.

The error text is no help in sorting the two apart. In the first incident the protocol really was at fault: the ingress re-emitted a hop-by-hop header that HTTP/2 forbids, and the stream was reset immediately after the 200 ^[6]. In the second, the identical browser error came out of a value in a Go struct ^[10]. Triage by symptom sends you to the ingress both times, and is correct once.

Worth noting what the offending header bought: nothing. HTTP/2 connections are multiplexed and persistent by design, and HTTP/1.1 already treats keep-alive as the default ^[7]. It survived in tutorials, got copied into a handler, and stayed there until a conformance check killed it ^[5].

The one default the author kept as protection is the idle timeout, and it holds only because of arithmetic. A heartbeat every 30 seconds against a 60-second IdleTimeout puts two writes inside every idle window ^[12], so one missed beat is survivable and two consecutive ones are not ^[2]. That is the real liveness budget of the endpoint, and it is nowhere in the config. ReadTimeout never fires at all, because an SSE client sends nothing after its request ^[12].

The cockpit incident is capacity rather than correctness. A browser allows roughly six connections per origin on HTTP/1.1; a permanent stream holds one, five remain for everything else, and a second tab exhausts the budget ^[14]. HTTP/2 collapses that into a single multiplexed tunnel that carries the stream alongside ordinary requests ^[15]. The author pulled SSE out of the cockpit ^[13], then reinstated it behind a check: the endpoint answers only when the request arrived through the HTTPS front, which sets a header the direct HTTP/1.1 origin does not ^[16]. Admission control on transport, enforced by the application.

Which is the same lesson as the August 2026 Go patch the author cites, where a timeout was not applied to HTTP/2 connections ^[17]. Configured is not the same as covering, and for anything that stays open, the reviewable question is which connections a deadline actually reaches ^[3].