veilletech.frCe qui se passe
L'auteur fait tourner deux points d'entrée SSE en production : un service de notification en Go sur Kubernetes derrière un proxy inverse, et une interface interne qui se rafraîchit sans rechargement de page.
Les deux ont cassé. À des endroits différents, avec le même symptôme.
La clé de tout le reste
Elle tient en une phrase : pour votre serveur, un flux SSE n'est pas un cas particulier — c'est une requête très lente.
Tout ce que vous avez mis en place pour vous protéger des requêtes lentes se retourne donc contre lui. C'est la raison pour laquelle les problèmes surgissent avant même d'atteindre votre code métier.
Les trois ruptures
L'en-tête Connection est illégal en HTTP/2. La plupart des tutoriels SSE le
font poser. En HTTP/2, cela casse la réponse.
Les délais par défaut du serveur Go coupent le flux. Un serveur configuré avec les précautions habituelles ferme la connexion au bout de trente secondes. Un flux permanent, par définition, dépasse cette limite dès le début.
En HTTP/1.1, un flux permanent gèle le reste de la page. Le navigateur limite le nombre de connexions simultanées par domaine ; une connexion qui ne se libère jamais en consomme une définitivement.
Le correctif d'août
Le billet cite un cas qui résume l'affaire : en août 2026, Go a corrigé un défaut où un délai n'était pas appliqué aux connexions HTTP/2.
La leçon vaut au-delà de SSE : un délai ne protège que ce qu'il couvre effectivement. Configurer un timeout ne dit rien de son application réelle selon le protocole, la version du serveur ou la couche traversée.
Ce qu'il faut retenir
Le sujet dépasse SSE. WebSocket, long-poll, tout ce qui reste ouvert se heurte aux mêmes réglages par défaut. Si vous livrez du streaming en production, la question à se poser n'est pas « ai-je configuré un délai » mais « sur quoi s'applique-t-il réellement ».
Source : dev.to