← HTTP/HTTPS: aplicações e diagnóstico
08 / 12 · 60 MIN

Redirects e integridade da transferência

Compara o pedido realmente enviado, o estado HTTP e a completude dos bytes antes de declarar um job recuperado.

Observar a cadeia completa

Um 200 final não descreve sozinho o percurso. O cliente pode ter enviado POST para uma operação, recebido Location e depois pedido um recibo ou uma página de login. Regista os estados e destinos por salto, o método e os campos necessários para explicar a diferença. Em dados reais, delimita a recolha e evita publicar credenciais. No laboratório, todos os corpos são fictícios e os eventos do servidor permitem comparar o que efetivamente chegou a cada endpoint, sem inferir o pedido apenas a partir do comando inicial.

Comparar 303 e 307 com um corpo controlado

O runner envia amount=7 com --data-binary e segue redirects com -L. No caso 303, observa POST com corpo seguido de GET sem esse corpo. No caso 307, observa POST com o mesmo corpo nos dois endpoints. Isto confirma a escolha do cliente naquele percurso. Não demonstra execução única de uma operação de negócio: o contrato precisa de explicar efeitos no primeiro endpoint e no destino. Antes de trocar um código de redirecionamento para corrigir uma integração, verifica se a mudança pode reenviar uma ação que já teve efeito.

O efeito de forçar o método

Acrescentar -X POST parece redundante, mas altera o resultado observado com 303. Neste curl 8.7.1, o segundo pedido mantém a palavra POST e perde o corpo inicial. O recibo recebe então um POST vazio, não um GET nem uma reprodução integral da submissão. O manual explica que -X muda a palavra do método, sem redefinir todo o comportamento do cliente. Compara os eventos antes de aumentar buffers ou culpar perda de rede. Novas opções do manual atual não devem ser assumidas como disponíveis na versão instalada.

Separar erro HTTP de erro de transferência

O endpoint de manutenção envia 503 e um corpo curto. Sem opção especial, curl termina com zero; com --fail-with-body termina com 22 e preserva o conteúdo. Noutro teste, o servidor envia 200, anuncia dez bytes e fecha depois de abc. O cliente termina com 18 porque a transferência ficou incompleta. São problemas distintos: um serviço pode comunicar corretamente uma indisponibilidade, enquanto outra resposta começa por sucesso e falha durante o corpo. O monitor precisa de estado HTTP, saída e critérios funcionais, com tratamento delimitado do conteúdo.

Não publicar um artefacto antes de o validar

Num pipeline de ficheiros, escrever diretamente no caminho consumido pelo passo seguinte expõe bytes parciais. Prepara uma área temporária, valida o resultado da transferência e os critérios acordados para o ficheiro, e só depois publica o artefacto. Não acrescentes a próxima resposta ao parcial sem um mecanismo de retoma que confirme versão e intervalo. O exercício não implementa uma política universal de checksums ou publicação atómica; pede que identifiques os controlos necessários ao contrato do consumidor. Um 200 sozinho não satisfaz esse contrato.

Limites, versões e conclusão do ensaio

O ciclo /loop termina com saída 47 depois do limite de dois redirects, totalizando três pedidos. Esse limite delimita o ensaio; a correção é investigar Location e a regra que cria o ciclo. No conjunto foram executadas nove observações com curl 8.7.1 e HTTP/1.1 em loopback. O manual consultado identifica 8.23.0. Não foram executados TLS, HTTP/2, HTTP/3, NGINX ou caches de browser, nem pedidos a sistemas reais. A evidência local ajuda a formular testes autorizados, mas não substitui a validação do percurso de produção.

# Re-run the isolated fixture:
python3 content/labs/http-conditions/run.py
# redirect303: POST(body) -> GET(empty)
# redirect307: POST(body) -> POST(body)
# forcedMethod: POST(body) -> POST(empty)
# partialTransfer: HTTP 200, curl exit 18
NA PRÁTICA

Caso fictício: o download devolve 200 mas fecha antes de completar Content-Length. O job mantém o parcial fora do caminho publicado, regista saída 18 e recupera uma cópia íntegra antes da reconciliação.

Armadilhas comuns

Evita -X por hábito, replay de POST sem contrato, loops sem limite e aceitação de um ficheiro parcial apenas porque o primeiro cabeçalho dizia 200.

Tópicos relacionados: Métodos, estados e repetição controlada · Cache, variantes e validação · Diagnóstico e orçamento de tempo

Leva esta ideia contigo

A evidência útil inclui o que chegou a cada destino e o que ficou utilizável no fim, com a versão e as opções do cliente registadas.

Criar conta

Referência: curl command-line manual · DR HTTP/HTTPS 2026-09; HTTP RFCs 9110–9114; selected TLS 1.3 and NGINX/curl guidance