Resumo

  • HTTP 206 confirma a entrega bem-sucedida dos intervalos declarados de uma representação selecionada; sozinho, não prova que intervalos obtidos separadamente formam um objeto completo.
  • Transferências retomadas e montagens em cache exigem um validador forte comum, cobertura exata dos intervalos e uma verificação final da representação.
  • Em uma resposta 206, Content-Length normalmente mede o corpo daquela mensagem, enquanto Content-Range informa a posição e o comprimento total da representação selecionada.
  • Um comprovante de montagem deve preservar a identidade da representação e cada intervalo aceito, em vez de tratar a contagem total de bytes como prova suficiente.

Imagine o download de um arquivo de dados de roteamento a partir de um armazenamento de objetos. A conexão cai na metade e o cliente pede os bytes restantes. Entre as duas solicitações, a origem substitui o snapshot por uma exportação mais nova, com tamanho nominal igual. As duas respostas são 206, todos os intervalos solicitados chegam e a barra alcança cem por cento. Mesmo assim, o arquivo reconstruído contém o início de uma representação e o fim de outra, porque nenhuma etiqueta forte vinculou as tentativas.

Esse é um cenário operacional hipotético, não uma acusação contra um provedor. O HTTP oferece os mecanismos para evitá-lo. O erro é exigir de uma resposta parcial uma prova que sua semântica não oferece.

O êxito de um intervalo tem significado limitado

O RFC 9110 define 206 Partial Content como o atendimento bem-sucedido de uma solicitação de intervalo mediante a transferência de uma ou mais partes da representação selecionada. O servidor afirma que enviou os intervalos declarados, não que o cliente já possui a representação inteira.

O destinatário precisa examinar Content-Type e cada Content-Range para saber o que a resposta contém e se outras solicitações são necessárias. Em um único intervalo, Content-Range traz os limites inclusivos e, em geral, o comprimento completo. Já Content-Length conta os octetos presentes na mensagem 206. Confundir essas medidas transforma uma resposta parcial correta em um sinal falso de conclusão.

Respostas com vários intervalos acrescentam outra obrigação: a ordem pode diferir da solicitação, e o servidor pode agregar intervalos ou omitir os que não consegue satisfazer. A cobertura deve ser calculada a partir dos intervalos efetivamente retornados, não da ordem pedida, do número de respostas ou da barra de progresso.

A continuidade pertence à representação, não à URL

Uma URL estável não garante bytes estáveis. Negociação de conteúdo, implantação, horário de geração e atualização da origem podem alterar a representação selecionada sem mudar o URI. Retomar com segurança exige prova de que os intervalos antigos e novos pertencem à mesma versão.

If-Range protege essa fronteira. O cliente envia o intervalo junto com um validador. Se ele ainda corresponder, o servidor pode retornar a parte solicitada; se não corresponder, ignora Range e envia a nova representação completa. O RFC 9110 proíbe uma etiqueta de entidade fraca em If-Range, pois a combinação byte a byte exige um comparador capaz de distinguir versões.

Por isso, uma resposta 200 depois de If-Range não é uma ineficiência a ser forçada de volta a 206. É evidência de que a cópia parcial anterior não pode mais ser ampliada com segurança. O estado antigo deve ser descartado e substituído pela representação completa atual.

Caches herdam a mesma obrigação

O RFC 9111 permite que um cache complete respostas incompletas com transferências posteriores, mas só combine intervalos que compartilhem o mesmo validador forte e obedeçam às regras de conteúdo parcial.

Taxa de acerto e quantidade de bytes armazenados não bastam. O operador precisa preservar a chave de cache e os campos de negociação, o validador de cada intervalo, as atualizações de cabeçalho e o estado de frescor ou revalidação. Gerenciadores de download, espelhos e gateways enfrentam o mesmo problema quando persistem fragmentos, mesmo que não se chamem caches.

Verifique a integridade na camada correta

O RFC 9530 separa dois escopos. Content-Digest cobre o conteúdo da mensagem HTTP. Repr-Digest cobre todos os dados da representação selecionada. Em 206, o primeiro pode verificar o segmento recebido; o segundo pode verificar o objeto reconstruído ao longo de várias solicitações ou conexões.

O digest não substitui o validador. O validador demonstra que os fragmentos pertencem à mesma versão; o Repr-Digest confere os bytes finais; a cobertura dos intervalos exclui lacunas e sobreposições escondidas por um contador total. Os campos de integridade também não definem autenticação, autorização ou privacidade. R063 trata apenas da coerência da representação recuperada.

Produza um comprovante de montagem por intervalos

Abra o comprovante quando aceitar a primeira resposta parcial. Registre URI, método, cabeçalhos que afetam a seleção, codificação, tipo de mídia, comprimento completo, validador forte, horário observado e se a resposta veio da origem, de um intermediário ou de armazenamento local.

Para cada parte, registre intervalo retornado, status, validador, fonte, estado de cache e digest do segmento, quando houver. Normalize o conjunto de intervalos para que sobreposições não inflem o progresso e lacunas continuem visíveis. Rejeite qualquer parte cuja identidade conflite com a representação congelada.

Feche o comprovante somente quando os intervalos cobrirem exatamente a representação e os bytes reconstruídos passarem no Repr-Digest esperado ou em outro hash obtido de forma independente. Se o validador forte mudar, desaparecer ou ficar ambíguo, descarte a montagem mista e recupere uma representação atual completa. Isso custa largura de banda, mas protege a afirmação mais valiosa: o objeto processado existiu como uma única representação.

Fontes