Códigos de status informativos 1xx

O que é uma resposta provisória

Toda outra família de status encerra a troca. Um 200, um 404 ou um 502 é a palavra final do servidor sobre aquela requisição. Um 1xx é diferente: o servidor envia a linha de status e quaisquer cabeçalhos, depois mantém a conexão aberta e envia uma segunda resposta mais tarde. A RFC 9110 exige que os clientes consigam ler uma ou mais respostas 1xx antes da final, e permite que qualquer cliente que não entenda um código 1xx específico o ignore.

A resposta provisória é descartada assim que a final chega, então a maioria das ferramentas nunca a mostra. O painel de rede do seu navegador, o log de acesso do seu servidor web e uma verificação de monitoramento todos reportam o status final. A resposta provisória fez o trabalho dela no nível de transporte e desapareceu.

Os códigos 1xx que você pode encontrar

• 100 Continue. O cliente enviou cabeçalhos de requisição com Expect: 100-continue e pausou antes de enviar um corpo grande. Um 100 significa "os cabeçalhos parecem bons, envie o corpo". Se o servidor fosse recusar a requisição de qualquer forma, ele pode responder com um erro final em vez disso, e o cliente nunca desperdiça banda enviando o payload. Esse é o único código 1xx que faz um trabalho útil em sites comuns, geralmente atrás de uploads de arquivos grandes e clientes de API como o curl.
• 101 Switching Protocols. O cliente pediu para mudar de protocolo com um cabeçalho Upgrade e o servidor concordou. Esse é o resultado normal e bem-sucedido de um handshake WebSocket, então um 101 em um log geralmente é um bom sinal, não um incidente.
• 102 Processing. Definido pela especificação WebDAV para requisições de longa duração, para que o cliente saiba que o servidor não travou. É raramente implementado fora do WebDAV e é improvável que você o encontre em um site normal.
• 103 Early Hints. O servidor envia cabeçalhos Link cedo, antes de terminar de gerar a página, para que o navegador possa começar a pré-carregar folhas de estilo, fontes ou scripts enquanto o HTML ainda está sendo produzido. É um recurso de desempenho, não um sinal de erro, e você normalmente o ativa deliberadamente na CDN ou na origem.

Por que um 1xx não é algo para corrigir

Um 1xx por si só não carrega nenhuma culpa. Não existe uma página que "devolve 100" ou "devolve 101" da forma que uma página pode devolver 404. Se você tem um problema e um 1xx está em algum ponto da troca, a informação interessante é sempre o código de status final que veio depois dele, ou o fato de que nenhuma resposta final chegou.

Os modos de falha reais perto de 1xx aparecem como um travamento ou um erro final, não como o próprio 1xx:

• Um proxy ou balanceador de carga antigo que não repassa respostas provisórias, então um cliente esperando por 100 Continue trava até o próprio timeout dele disparar.
• Um upgrade de WebSocket que nunca chega a um 101 porque um proxy na frente da aplicação remove os cabeçalhos Upgrade e Connection. A conexão então recorre a outra coisa ou falha completamente.
• Early hints emitidos com links para recursos que não existem mais, o que desperdiça requisições sem quebrar a página.

Como ver uma resposta 1xx você mesmo

1. Use um cliente detalhado. O curl -I comum mostra só os cabeçalhos da resposta final, então peça a troca completa em vez disso:

   curl -v -H "Expect: 100-continue" --data-binary @big.bin https://example.com/upload

   Um servidor cooperativo responde HTTP/1.1 100 Continue antes de o corpo sair, e depois o 2xx ou 4xx final.
2. Para um caminho WebSocket, verifique se o handshake chega a HTTP/1.1 101 Switching Protocols. Se não chegar, olhe primeiro a camada de proxy: cabeçalhos de upgrade são hop-by-hop, e várias configurações comuns de proxy reverso os descartam por padrão.
3. Para early hints, solicite a página e procure por um bloco 103 antes da resposta final. Nem todo intermediário o repassa, então um 103 ausente nem sempre significa que a origem não está enviando um.
4. Se um upload grande travar sem nenhuma resposta, tente de novo sem o cabeçalho Expect. Se a nova tentativa der certo, algo entre você e a origem está engolindo respostas provisórias.

Monitorando uma troca que você não consegue ver

Como códigos 1xx nunca chegam a um log ou painel, o que você monitora é a resposta final e quanto tempo levou para chegar. Um caminho de upload travado em uma resposta provisória parece, de fora, exatamente como um endpoint lento ou dando timeout, e uma verificação externa vê isso na hora. A HostTracker roda verificações a partir de mais de 300 pontos de verificação em 158 cidades, então uma requisição que trava atrás de um caminho de rede específico é distinguível de uma indisponibilidade genuína. Rode uma URL pela ferramenta de verificação HTTP para ver o status final e o tempo de resposta. Os guias de códigos de sucesso 2xx e códigos de redirecionamento 3xx cobrem as respostas que de fato encerram uma troca.