Summary

  • A revisão 05 de Byte Range PATCH descreve como um servidor sem suporte a PUT parcial pode ignorar Content-Range e trocar todo o recurso pelo trecho recebido.
  • O tipo message/byterange leva a posição para um documento PATCH de uma faixa contígua. Sem uma faixa conhecida, o servidor deve rejeitar o pedido com 400 ou 422.
  • O tamanho declarado de uma parte deve bater exatamente com a faixa. Se o servidor permitir arquivos esparsos, não pode expor conteúdo não inicializado.

O exemplo do documento começa com 0123456789 e uma quebra de linha. O cliente deseja escrever wxyz nas posições 2 a 5. A resposta correta é um arquivo que começa 01wxyz6789 e mantém a quebra. Em um receptor que entende PUT apenas como substituição completa, a saída pode virar wxyz. O erro é maior que o pacote: uma parte do arquivo ganhou autoridade sobre o arquivo inteiro.

O campo Content-Range não obriga um servidor genérico a interpretar PUT como correção parcial. A seção 2 do rascunho explica que o comportamento depende de suporte específico. Sem ele, o servidor pode ignorar o campo e fazer a substituição habitual. O cliente escreveu a intenção com precisão; o receptor executou a operação que conhece. A falha está na ausência de uma capacidade comum, detectada tarde demais.

PATCH oferece um ponto mais firme para negociar o significado. message/byterange representa uma faixa; multipart/byteranges reúne várias; application/byteranges propõe uma representação binária. No primeiro formato, Content-Range: bytes 2-5/12 faz parte do documento PATCH que contém wxyz. O servidor que aceita o tipo assume a escrita naquele intervalo. Aquele que não reconhece o formato deve recusar o pedido antes de modificar o arquivo. Uma recusa explícita protege mais dados que um sucesso com semântica diferente.

Quatro bytes exigem uma conta exata

Cada parte identifica um intervalo contíguo. Sem posição conhecida, a resposta exigida é 400 ou 422. Se a parte trouxer Content-Length, o número precisa corresponder ao tamanho do intervalo. A conta impede que uma carga de cinco bytes se esconda dentro de uma instrução de quatro. Para fluxos sem comprimento final conhecido, Content-Offset permite indicar o ponto de partida. A incerteza sobre o fim do fluxo não autoriza o servidor a adivinhar onde ele começa.

O limite físico do recurso também importa. Escrever junto ao último byte amplia o arquivo. Saltar além dele cria uma lacuna sem conteúdo definido. O rascunho recomenda rejeitar esse salto. Se um servidor aceitar gravações esparsas, deve impedir a divulgação de memória não inicializada e deveria preencher os espaços indefinidos com zeros. A verificação tem de ler o objeto resultante; o código de resposta sozinho não descreve os bytes guardados.

Outra seção oferece Prefer: transaction=atomic ou transaction=persist para decidir o que fazer com uma transmissão interrompida. O servidor deveria indicar a preferência atendida em Preference-Applied. Trata-se de conservar ou reverter o estado parcial. Antes disso, o receptor precisa concordar que o pedido é uma alteração dentro do arquivo, e não a publicação de um arquivo novo de quatro bytes.

A RFC 5789 define Accept-Patch para anunciar tipos de documento aceitos. Falta uma prova pública em vários servidores que envie o mesmo PUT com intervalo e o mesmo PATCH message/byterange, anotando bytes antes e depois, status e ETag. O ensaio mostraria a fronteira de capacidade na prática.

Rascunho e estado · RFC 5789 · RFC 9110