Tempos mortos dos proxies durante traballos HTTP longos
Escolle sondaxe ou un formato de fluxo definido cando o traballo longo do servidor atopa o límite de inactividade dun proxy, en lugar de inserir bytes arbitrarios na resposta final.
Se un servizo permanece en silencio durante minutos e un proxy esgota o tempo, escolle que debe recibir o cliente antes de engadir bytes de latexo. Ampliar un temporizador pode axudar a unha espera; o contrato de resposta determina que progreso é válido.
| Deseño da aplicación | Contrato de progreso |
|---|---|
| Tarefa asíncrona | 202 Accepted cunha representación que describe a monitorización, seguida de solicitudes de estado finitas e estados explícitos de finalización/fallo |
| Fluxo Server-Sent Events | Content-Type: text/event-stream e rexistros que o cliente SSE entende |
202 non promete que a tarefa teña éxito. Para SSE, un rexistro de comentario pode verse así:
: heartbeat
Os dous puntos convérteno nun comentario en lugar dun evento da aplicación. As notas de autoría de HTML suxiren comentarios periódicos aproximadamente cada 15 segundos contra certos comportamentos antigos de inactividade de proxies; iso é unha guía, non unha garantía universal de tempo de espera.
Remata as cabeceiras e asegúrate de que a aplicación/pila de servizo libera os rexistros en lugar de almacenalos localmente. Os bytes aínda non enviados non poden manter activo un intermediario posterior.
Non insiras comentarios SSE en contido JSON ou binario común. Un chunk de lonxitude cero HTTP/1.1 remata un corpo chunked, así que non é un latexo baleiro repetible.
Conserva un prazo de operación e unha política de cancelación. A actividade do tráfico por si soa non mostra un progreso útil da tarefa nin un resultado final válido.