Resumo

  • O deslocamento indica onde um fragmento se encaixa, mas não identifica a versão da representação à qual ele pertence.
  • Com Range e If-Range, uma correspondência forte mantém o processamento parcial; uma divergência faz o servidor ignorar a faixa e devolver a representação atual completa.
  • O mecanismo economiza uma segunda requisição e evita montagem entre versões, sem garantir suporte a faixas, recebimento, armazenamento, autenticidade ou correção do conteúdo.

O próximo byte podia pertencer a outro arquivo

Uma conexão cai depois de entregar os primeiros três megabytes de um pacote. O cliente guarda o material e, mais tarde, pede os bytes a partir de 3.145.728. Se o pacote não mudou, a operação evita uma repetição inútil. Se houve uma nova compilação, o mesmo deslocamento agora descreve outro fluxo. A resposta pode estar impecável e, ao ser anexada ao prefixo antigo, formar um objeto que nunca existiu na origem.

O problema não era descobrir que a conexão terminou. Era transportar identidade entre duas requisições separadas. Range descrevia a posição faltante, mas posição não é versão. O cliente precisava apresentar também uma evidência de que os bytes já guardados ainda correspondiam à representação selecionada pelo servidor.

Em 1997, a RFC 2068 introduziu If-Range no primeiro HTTP/1.1 de trilha normativa. Uma requisição parcial com precondição comum poderia falhar depois de uma alteração. Nesse caso, o cliente precisaria pedir novamente o corpo atual inteiro. A nova condição encurtou esse caminho: se a entidade permanecesse igual, devolver as partes ausentes; caso contrário, devolver a entidade nova por completo.

A RFC 2616, de 1999, preservou a bifurcação. Uma etiqueta coincidente levava à subfaixa em 206 Partial Content; uma etiqueta diferente levava ao corpo inteiro em 200 OK. A condição falsa não negava a leitura. Ela retirava apenas a licença para aproveitar os bytes de uma versão anterior.

Uma requisição aceitava duas formas de sucesso

O pedido poderia trazer:

Range: bytes=3145728-
If-Range: "pacote-91"

O cliente aceitava poucos bytes somente se "pacote-91" ainda fosse um validador forte da representação atual. Se não fosse, queria o objeto corrente inteiro. O servidor então ignorava Range, e o cliente deveria substituir o fragmento antigo pelo corpo de 200, nunca anexar um corpo completo ao que já tinha.

Essa semântica difere das demais precondições. If-Match pode impedir uma operação e produzir 412 Precondition Failed. If-None-Match pode produzir 304 Not Modified sem corpo. If-Range não escolhe entre executar e recusar. Ele escolhe entre uma resposta parcial econômica e uma resposta completa coerente.

A RFC 7233 separou as requisições de faixa em 2014. O cliente não deve gerar If-Range sem Range; o servidor ignora o campo quando não há faixa ou quando o alvo não oferece essa capacidade. Se o validador coincide, a faixa deve ser processada; se diverge, a faixa precisa ser ignorada. O atalho poupa uma nova requisição, mas não cria suporte que a origem não possua.

Na consolidação atual, a RFC 9110 explicita a ordem: GET com os dois campos, condição verdadeira e faixa aplicável conduz a 206; nos demais casos, Range é ignorado e a resposta é 200. Falhas detectáveis antes, redirecionamentos e seleção de representação continuam prevalecendo. O validador não comanda o restante do método.

Fragmentos exigiam igualdade forte

Validadores fracos existem porque duas respostas podem ser semanticamente equivalentes sem terem os mesmos bytes. Para decidir se uma página em cache ainda serve, essa aproximação pode bastar. Para colocar um trecho depois de outro, não. Uma única inserção no começo muda a posição de tudo o que vem depois.

A RFC 7232 define que o validador forte muda quando os dados observáveis da representação mudam e pode ser usado em faixas parciais. O fraco serve quando igualdade exata não é necessária. Por isso, um cliente não pode inserir uma ETag fraca em If-Range. Uma data Last-Modified só entra quando não há ETag e a data satisfaz os requisitos de força.

Datas podem ser enganosas porque a granularidade do relógio talvez seja menor que a frequência de atualização. Duas edições podem receber o mesmo segundo. A data de If-Range é comparada exatamente com Last-Modified, não pela relação “anterior ou igual” de If-Unmodified-Since. Se a evidência temporal é fraca, o caminho parcial deve ser fechado.

Uma ETag também não é necessariamente um hash. Ela é opaca. Ser forte significa que a origem não a reutiliza entre representações observavelmente diferentes daquele recurso no escopo relevante. Não autentica quem publicou, não garante que o arquivo está correto e não prova equivalência com outra URL que mostre o mesmo texto. A RFC 2616 já negava essa conclusão entre URIs distintas.

A coincidência ainda não prometia 206

Mesmo depois de comparar, o servidor verifica a unidade, a sintaxe, a extensão atual e a viabilidade da faixa. Uma faixa suportada, válida e satisfatível normalmente recebe 206 Partial Content. Uma única parte inclui Content-Range; várias usam multipart/byteranges. Quando nenhuma posição solicitada existe na representação atual, pode haver 416 Range Not Satisfiable.

Content-Range localiza o corpo recebido. Não prova a versão do prefixo armazenado. Essa continuidade depende do validador forte compartilhado. Tampouco a coincidência demonstra que o cliente recebeu tudo, gravou em ordem ou manteve o resultado.

Os riscos têm pesos diferentes. Uma divergência falsa retransmite o arquivo completo: desperdiça recursos, mas entrega uma cópia coerente. Uma coincidência falsa pode criar silenciosamente um híbrido. O desenho prefere pagar uma transferência visível a inventar uma continuidade invisível.

O cache passou a custodiar partes

Um cache pode guardar um 200 incompleto, um 206 ou trechos separados. Ao reuni-los, assume responsabilidade por sua origem. A RFC 7234 permite armazenar conteúdo incompleto apenas quando o cache entende Range e Content-Range. Faixas só podem ser combinadas se todas compartilham o mesmo validador forte.

Cobrir todos os deslocamentos não basta. Um começo de segunda-feira, um meio de terça e um fim de quarta podem preencher a extensão e ainda assim pertencer a três versões. O cache precisa atualizar os metadados conforme as regras e não pode apresentar como completo algo que ainda é parcial.

A especificação vigente, RFC 9111, mantém a separação. O cache pode completar uma resposta com nova requisição de faixa, mas só a reutiliza como total depois de realmente completar. Conteúdo parcial precisa ser marcado como 206. If-Range não executa armazenamento ou montagem; apenas fornece a condição de versão para uma resposta.

Uma trilha auditável deve guardar alvo, entradas de negociação, Range, validador anterior, validador atual, tipo de comparação, status, Content-Range e hash do objeto final. O servidor conhece o ramo que enviou. O cliente ou cache conhece as partes que recebeu e uniu. Nenhum registro isolado comprova todo o percurso.

Continuidade sem cadastro mundial de versões

O protocolo não criou um registro universal para numerar cada versão nem um bloqueio que impedisse a origem de mudar enquanto clientes estavam desconectados. A origem gerava o validador; o cliente o guardava com seus bytes; o servidor comparava o estado atual; o cache respondia pelas partes sob sua guarda.

A pergunta compartilhada permaneceu pequena: esta nova faixa ainda pode completar a representação que já possuo? Uma resposta negativa retirava a economia, não o acesso ao conteúdo corrente. Essa limitação preservou autonomia operacional e, ao mesmo tempo, ofereceu uma regra interoperável.

As RFCs definem a regra, não comprovam a conduta de produtos atuais. Elas não demonstram que uma ETag real é forte, que um intermediário a preservou, que o servidor suporta faixas ou que o arquivo final foi persistido. Essa verificação exige capturas, entradas de seleção, histórico de validadores, hashes dos trechos e registro da montagem.