Código de status HTTP · Informativos (1xx)
102 Processing
O 102 Processing é uma resposta provisória que um servidor WebDAV envia para dizer que recebeu o pedido completo e ainda está processando, para o cliente não desistir por tempo esgotado. Veio da RFC 2518 e foi retirado da RFC 4918 em 2007 porque quase ninguém o implementou.
| Classe | 1xx, Informativos |
|---|---|
| Definido em | RFC 2518 §10.1 |
| Pode ir para o cache por padrão | Não |
| Pode repetir o pedido | Não se aplica; continue esperando a resposta final |
| Cabeçalhos relevantes | Nenhum específico deste código |
| Situação | Obsoleto: Definido na RFC 2518 (WebDAV, 1999) e removido da sucessora RFC 4918 por falta de implementações; o registro da IANA ainda aponta para a RFC 2518. |
O que significa o 102
A RFC 2518, seção 10.1, sugeria enviar o 102 quando um método fosse levar mais de uns 20 segundos, como um COPY ou DELETE numa coleção grande com Depth: infinity, e exigia uma resposta final ao terminar. Go e Node ainda expõem o código (http.StatusProcessing, response.writeProcessing()), mas a maioria dos clientes HTTP descarta o 102 como qualquer 1xx desconhecido.
Em APIs novas, uma operação demorada fica melhor como 202 Accepted mais um recurso de status que o cliente consulta, o que sobrevive a proxies com timeout curto e a conexões que caem.
Quando usar
- Só para clientes no estilo WebDAV que o esperam, enviado de tempos em tempos durante uma operação que passa bem do timeout do cliente.
Como enviar um 102
Route handlers do Next.js e o FastAPI não emitem respostas 1xx. Para qualquer coisa nova, prefira 202 Accepted com uma URL de status.
app.post('/imports', async (req, res) => {
// Interim "102 Processing" every 15 s while the import runs
const timer = setInterval(() => res.writeProcessing(), 15_000);
try {
const result = await runLongImport(req);
res.status(200).send(result);
} finally {
clearInterval(timer);
}
});mux.HandleFunc("POST /imports", func(w http.ResponseWriter, r *http.Request) {
done := make(chan []byte)
go func() { done <- runLongImport(r) }()
for {
select {
case result := <-done:
w.Header().Set("Content-Type", "application/json")
w.WriteHeader(http.StatusOK)
w.Write(result)
return
case <-time.After(15 * time.Second):
w.WriteHeader(http.StatusProcessing) // interim 102, sent immediately
}
}
})Costuma ser confundido com
- 102 vs 202
- O 202 encerra o pedido na hora e leva a espera para um recurso de status separado; o 102 mantém o pedido original aberto até a resposta final.
- 102 vs 103
- O 103 Early Hints é o 1xx moderno que os navegadores usam; ele traz cabeçalhos Link, enquanto o 102 só diz "ainda processando".
Perguntas frequentes
- O 102 Processing está obsoleto?
- Na prática, sim. A RFC 4918, que substituiu a RFC 2518 em 2007, removeu o código por falta de implementação. Ele continua no registro da IANA apontando para a RFC 2518, então ainda é válido, só é pouco usado.
- Navegadores entendem o 102 Processing?
- O navegador aceita e ignora, como qualquer resposta provisória; ele não mostra nada ao usuário. O código foi pensado para clientes WebDAV.
- O que usar no lugar do 102 em pedidos demorados?
- Responda 202 Accepted com Location ou um link para o recurso da tarefa e deixe o cliente consultar, ou transmita o progresso por Server-Sent Events ou WebSocket.
Revisado em por Arielton Oberek.