Skip to main content

Server-Sent Events (SSE)

Pitfalls​

SSE appears simple on the surface, but has several production-readiness issues that are not immediately obvious.

Proxy Buffering​

Network proxies between the server and client can buffer SSE packets indefinitely. SSE uses Transfer-Encoding: chunked without a Content-Length, so intermediate proxies see no defined message boundary and may hold packets until the stream closes, thinking they are helping by accumulating data. The SSE specification actually permits this behavior, and no headers can reliably override it.

This means if you don't control the network infrastructure between your server and client, you cannot guarantee SSE will deliver events in real-time.

HTTP Chunking Reliability​

The SSE specification itself warns:

"HTTP chunking can have unexpected negative effects on the reliability of this protocol."

The spec suggests disabling chunking "where possible," but this recommendation is meaningless for developers who don't control the network infrastructure between their servers and clients.

Dangerous for Synchronous Response Patterns​

Using SSE to deliver responses to client-initiated requests (e.g., login results, form submissions) creates critical failures. When events never arrive due to proxy buffering, clients hang indefinitely with no indication of failure. This can result in delays of 20+ minutes for operations that should complete in seconds.

Misleading Ecosystem Documentation​

Many articles and tutorials promote SSE's automatic reconnection and simplicity without adequately warning about the proxy buffering limitation. The critical caveats exist buried in the spec's fine print, leading developers to adopt SSE for use cases (chat, real-time messaging) where it may silently fail on uncontrolled networks.

Alternatives​

  • Long polling: Less elegant but more reliable across diverse network infrastructure since each response completes as a normal HTTP response, avoiding proxy buffering issues.
  • WebSocket: Full-duplex communication that performs an explicit protocol upgrade, making it less susceptible to HTTP proxy interference.

References​