Expiration d'inactivité des proxys pendant les longs travaux HTTP
Choisissez l'interrogation ou un format de flux défini lorsque le long travail du serveur rencontre la limite d'inactivité d'un proxy, plutôt que d'insérer des octets arbitraires dans la réponse finale.
Si un service reste silencieux pendant des minutes et qu'un proxy expire, choisissez ce que le client doit recevoir avant d'ajouter des octets de battement. Prolonger un minuteur peut aider une attente ; le contrat de réponse détermine quelle progression est valide.
| Conception de l'application | Contrat de progression |
|---|---|
| Tâche asynchrone | 202 Accepted avec une représentation décrivant la surveillance, suivie de demandes d'état finies et d'états explicites d'achèvement/d'échec |
| Flux Server-Sent Events | Content-Type: text/event-stream et enregistrements que le client SSE comprend |
202 ne promet pas que la tâche réussira. Pour SSE, un enregistrement de commentaire peut ressembler à ceci :
: heartbeat
Les deux-points en font un commentaire plutôt qu'un événement d'application. Les notes de rédaction de HTML suggèrent des commentaires périodiques environ toutes les 15 secondes contre certains anciens comportements d'inactivité des proxys ; c'est une indication, pas une garantie universelle d'expiration.
Terminez les en-têtes et assurez-vous que la pile applicative/de service libère les enregistrements au lieu de les mettre en mémoire tampon localement. Les octets pas encore envoyés ne peuvent pas maintenir actif un intermédiaire en aval.
N'insérez pas de commentaires SSE dans un contenu JSON ou binaire ordinaire. Un chunk de longueur nulle HTTP/1.1 termine un corps chunked, ce n'est donc pas un battement vide répétable.
Conservez une échéance d'opération et une politique d'annulation. L'activité du trafic seule ne montre pas une progression utile de la tâche ni un résultat final valide.