Tempos limite de inatividade do proxy durante trabalhos HTTP longos
Escolha sondagem ou um formato de streaming definido quando o trabalho longo do servidor encontra o limite de inatividade de um proxy, em vez de inserir bytes arbitrários na resposta final.
Se um serviço permanece em silêncio por minutos e um proxy atinge o tempo limite, escolha o que o cliente deve receber antes de adicionar bytes de batimento. Estender um temporizador pode ajudar uma espera; o contrato de resposta determina qual progresso é válido.
| Design da aplicação | Contrato de progresso |
|---|---|
| Trabalho assíncrono | 202 Accepted com uma representação que descreve a monitorização, seguida de pedidos de estado finitos e estados explícitos de conclusão/falha |
| Fluxo Server-Sent Events | Content-Type: text/event-stream e registos que o cliente SSE compreende |
202 não promete que o trabalho terá sucesso. Para SSE, um registo de comentário pode parecer assim:
: heartbeat
Os dois pontos tornam-no um comentário em vez de um evento da aplicação. As notas de autoria do HTML sugerem comentários periódicos aproximadamente a cada 15 segundos contra certos comportamentos antigos de inatividade de proxies; isso é orientação, não uma garantia universal de tempo limite.
Conclua os cabeçalhos e garanta que a aplicação/pilha de serviço liberta os registos em vez de os armazenar localmente em buffer. Os bytes ainda não enviados não podem manter ativo um intermediário a jusante.
Não insira comentários SSE em conteúdo JSON ou binário comum. Um chunk de comprimento zero HTTP/1.1 termina um corpo chunked, portanto não é um batimento vazio repetível.
Mantenha um prazo de operação e uma política de cancelamento. A atividade de tráfego por si só não mostra progresso útil do trabalho nem um resultado final válido.