Resumo

  • O RFC 3229 ampliou o GET condicional: o cliente nomeia instâncias guardadas em If-None-Match, anuncia transformações aceitas em A-IM e pode receber 226 com a receita IM em vez de outra cópia inteira.
  • A reconstrução tem três identidades. Delta-Base aponta a base antiga, o corpo leva as instruções e o ETag da resposta identifica a instância atual reconstruída, jamais os bytes do delta.
  • O novo status também protegia caches antigos. Ignorar um cabeçalho desconhecido poderia fazer uma diferença ser armazenada e servida como recurso inteiro; 226 tornou a ruptura semântica visível.

A validação economizava tudo ou nada

Se uma resposta guardada continuava atual, 304 Not Modified evitava a transferência. Se havia qualquer mudança, o caminho normal mandava outra vez o valor completo.

O cache era um testemunho binário: reutilizável sem alteração ou inútil para reduzir a próxima resposta. Uma linha nova fazia todas as linhas antigas voltarem pela rede.

O RFC 3229, publicado em janeiro de 2002, transformou a cópia anterior em matéria-prima. O servidor poderia calcular a diferença para a instância atual e enviar apenas as instruções de reconstrução.

A extensão era opcional, buscava reduzir a média sem nova ida e volta e precisava conviver com HTTP/1.0 e HTTP/1.1 alheios a ela. Não prometia que todo conteúdo produziria um delta vantajoso.

Delta não era compressão nem intervalo

O documento define instância como o valor que um GET 200 devolveria para a variante selecionada depois do content coding, mas antes da manipulação de instância e do transfer coding.

Compressão normalmente se desfaz sem uma cópia antiga. Delta precisa da base específica. Range escolhe coordenadas numa instância atual; delta descreve a passagem entre duas instâncias. Os três podem reduzir bytes, mas não compartilham a mesma prova.

Também não é PATCH. O corpo 226 responde a GET e ajuda o destinatário a recuperar o estado atual. Não manda alterar o recurso. RFC 3229 limitou o mecanismo definido às respostas de GET.

As fronteiras evitam que toda técnica incremental pareça intercambiável.

O cliente precisava provar o ponto de partida

If-None-Match lista ETags de instâncias antigas que o cliente ainda possui. A-IM lista as manipulações que ele sabe aplicar.

Se a etiqueta ainda é atual, 304 basta. Se mudou, um servidor capaz pode escolher uma base oferecida e produzir um delta compatível. Sem a versão, o algoritmo ou uma economia razoável, pode retornar 200.

É uma oferta, não uma ordem. O cliente controla bases e formatos disponíveis. A origem controla histórico, cálculo, escolha da base e retorno à cópia inteira.

Nenhuma “diferença” é segura até que ambos concordem de qual estado ela parte e qual operação a interpreta.

Um corpo coordenava três objetos

A base antiga já está no cache. O corpo 226 leva instruções. Aplicá-las produz a instância atual.

Se várias etiquetas foram oferecidas, Delta-Base revela a escolhida. O ETag da resposta nomeia o resultado. O RFC ressalta que não nomeia o delta, porque o delta não é uma instância autônoma.

O corpo pode estar correto e ser inútil sozinho. Seu sentido depende de base, transformação e identidade de saída exatas.

Content-Length mede o delta transportado, não o tamanho da instância reconstruída. Confundir as medidas converte economia em truncamento aparente.

A ordem das transformações integrava a linhagem

A sequência conceitual escolhe recurso e variante, aplica content coding, atribui o ETag da instância, aplica delta ou range e, por fim, transfer coding.

Trocar etapas pode trocar bytes. Delta seguido de range não precisa equivaler a range seguido de delta. Compressão como content coding participa da instância; como manipulação posterior ocupa outro nível.

A-IM e IM preservam a ordem. Um cache não pode guardar somente nomes e reordená-los ao reutilizar. Base, algoritmo, parâmetros e sequência compõem a receita.

A economia é confiável quando a explicação que devolve sentido aos bytes viaja com eles.

Um novo 2xx conteve caches desconhecedores

Os autores hesitaram em criar outro status. A base instalada tornou isso necessário.

HTTP costuma mandar ignorar campos desconhecidos. Um proxy antigo poderia ignorar IM, guardar o delta e depois entregá-lo como se fosse o recurso inteiro. A compatibilidade da extensão criaria corrupção silenciosa.

O desconhecido 226 formava uma barreira mais visível. Segundo o RFC, proxies existentes pareciam encaminhar estados desconhecidos sem armazená-los. Podiam transportar sem fingir compreensão.

O texto ainda avisa que Vary: If-None-Match, A-IM não bastava em pelo menos um caminho de validação incorreta. A diferença precisava aparecer onde a lógica antiga não a apagasse facilmente.

IM descrevia a receita; 226 impedia supor o todo

Uma resposta delta deve usar 226 e incluir IM com ao menos o coding usado. A requisição deve ter aceitado a manipulação em A-IM e fornecido uma base em If-None-Match.

O status informa que GET foi satisfeito mediante uma ou mais manipulações. Dependendo delas, a instância atual só fica disponível quando combinada com respostas passadas ou futuras.

226 não é sinônimo exclusivo de delta. O quadro admite combinações, inclusive com range. IM registra a sequência; 226 avisa que o corpo não pode ser presumido inteiro.

A frase curta “IM Used” não substitui os campos estruturados que executam a reconstrução.

Um cache capaz podia reconstruir e converter

Proibir todo armazenamento eliminaria parte do ganho. O RFC separa o cache ignorante daquele capaz de seguir o contrato inteiro.

O cache capaz pode desfazer todas as manipulações, recuperar a instância e armazená-la como 200. Pode manter apenas a seleção de range e guardar 206. Ou pode reter o 226 bruto sob regras específicas.

Reuso bruto exige que o próximo pedido aceite manipulações, parâmetros e ordem compatíveis, além das condições de frescor, base e identidade. Um delta guardado não vira variante independente.

A diretiva Cache-Control im marca a fronteira: no-store segura caches comuns; apenas implementações que entendem 226, A-IM e IM podem usar as instruções reservadas a essa capacidade.

Preservar o passado cobrava armazenamento e CPU

O delta só existe se uma base útil sobrevive. O cliente pode guardar várias instâncias e oferecer vários ETags. Se a origem também tem histórico, escolhe a base apropriada e a declara em Delta-Base.

Mas espaço e histórico são finitos, e comparar candidatos gasta CPU, memória e I/O. Uma dica de retenção não promete conservação eterna.

A otimização muda incentivos: uma cópia antiga pode permanecer não para exibição, mas para reconstrução futura. A origem só deve guardar versões ou pré-calcular deltas quando a economia esperada paga o custo.

A liberdade de responder 200 é controle operacional. Delta maior, lento ou indisponível deve ceder ao todo.

Os registros atuais preservam o vocabulário

O registro de status HTTP da IANA mantém 226 IM Used ligado ao RFC 3229. O registro de campos HTTP da IANA lista A-IM, Delta-Base e IM como permanentes.

Registro não prova adoção ampla. Preserva uma correspondência entre símbolos e contrato, impedindo que outra técnica incremental reutilize os nomes com significado incompatível.

A história relevante não é a vitória universal do delta. É a quantidade de identidade que o HTTP precisou guardar para transmitir menos sem entregar outra coisa.

A cópia só aparecia depois da reconstrução

No 226, mensagem na rede e representação atual podiam ser objetos diferentes. A rede carregava uma transformação sem chamar a transformação de resultado completo.

O cliente provava a base, o servidor escolhia, IM fixava a ordem, o ETag identificava a saída e o cache entendia a cadeia ou recusava convertê-la em documento.

Sem linhagem, o delta não é verdade eficiente. É uma sequência curta carregada de pressuposto invisível.

HTTP 226 tornou o pressuposto explícito: o destinatário não recebia a cópia nova, mas um modo verificável de construí-la a partir da cópia que provava já possuir.