Resumo

  • draft-ietf-httpbis-resumable-upload-12 permite anexar partes a um recurso temporário e usa Upload-Offset para confirmar o prefixo já processado, sem transformar progresso em prova de integridade ou aceitação.
  • Scanners, digests, autorização no momento da finalização e resposta do recurso-alvo precisam de recibos próprios; verificar apenas cada PATCH pode não revelar um padrão que surge depois da montagem.

O primeiro trecho terminou com uma sequência inofensiva. O segundo começou com outra. O scanner aprovou ambos porque avaliou cada PATCH como uma unidade completa. Quando o servidor juntou as partes, a fronteira desapareceu e as duas sequências formaram o padrão que a política pretendia bloquear.

O offset estava correto. Nenhum byte precisaria ser retransmitido. O problema foi acreditar que a exatidão do mecanismo de retomada também certificava o conteúdo reunido.

A revisão 12 de Resumable Uploads for HTTP, publicada em 6 de julho de 2026, define uma forma de continuar uploads HTTP após cancelamento ou queda da conexão. É um Internet-Draft ativo do grupo HTTP, destinado ao Standards Track e com expiração em 7 de janeiro de 2027. Não é RFC, relatório de produção, teste de interoperabilidade nem evidência de adoção. Seu valor para liderança aparece na separação entre uma recepção recuperável e um objeto digno de ação.

O recurso de upload é provisório por desenho

A requisição inicial aponta para o recurso que entende o método e o objetivo da operação. O servidor pode criar um recurso de upload separado, temporário e dedicado a uma representação. O cliente consulta seu progresso, anexa mais dados ou cancela.

Essa camada provisória preserva continuidade. Ela não herda automaticamente a autoridade do alvo. Uma URI de upload pode existir sem que o documento, mídia ou registro final tenha sido criado. O direito de anexar a uma área temporária também não significa direito permanente de publicar ou substituir o objeto de destino.

Depois da conclusão, o servidor pode remover o recurso imediatamente ou mantê-lo por algum tempo para permitir uma consulta quando a última resposta se perdeu. Portanto, o desaparecimento posterior da URI não é um veredito universal. A política de retenção e o registro do alvo são necessários para interpretar o fato.

Offset é um recibo de processamento

Upload-Offset conta bytes da representação processados pela aplicação do recurso de upload. Ele não copia a contagem do transporte. Dados podem ter sido entregues e reconhecidos pela conexão enquanto ainda esperam processamento na camada HTTP ou no serviço.

Quando aparece numa resposta, o offset reconhece o prefixo processado e garante que ele não precisará ser retransmitido. Isso autoriza o cliente a liberar buffers ou descartar partes locais mantidas apenas para repetição. É uma garantia operacional forte.

O recibo não declara que os bytes passaram por digest, varredura, aprovação, armazenamento final, replicação ou publicação. Tampouco diz que a operação do recurso original produziu o efeito desejado. O sistema deve repetir a frase exata: “este prefixo foi processado por este recurso temporário”.

O valor não pode diminuir. Se o servidor perder qualquer parte do estado, deve desativar o recurso e rejeitar novas interações. Uma retomada inventada preservaria aparência de disponibilidade, mas poderia duplicar, omitir ou deslocar bytes.

Tamanho não fecha o estado

O comprimento representa o tamanho total quando conhecido. O offset representa o prefixo processado. Mesmo que sejam iguais, o upload pode continuar explicitamente incompleto. Essa regra impede que dois números tomem o lugar da intenção do emissor.

Uma fonte por streaming pode ter esgotado os bytes atuais sem declarar fim. Um cliente pode enviar todo o conteúdo em várias requisições e usar um PATCH vazio para marcar a conclusão. Upload-Complete é o estado que realiza essa transição.

Numa resposta de criação ou anexo, o valor verdadeiro significa que voltam a valer as semânticas do recurso inicialmente direcionado. O alvo pode responder cedo e tornar a marca verdadeira mesmo sem a representação completa ter sido transmitida. Logo, “complete” não é sinônimo mecânico de “todos os bytes atravessaram”; é uma decisão de protocolo do alvo.

A montagem muda a unidade de segurança

Um digest de conteúdo ou de representação exige regra própria. É preciso registrar quais bytes foram cobertos, qual codificação foi considerada, quando ocorreu a comparação e qual estado é invalidado na falha. A contagem de progresso não substitui essa prova.

O draft chama atenção para scanners que esperam receber a representação inteira em uma única mensagem. Uma carga retomável pode repartir o conteúdo e atravessar esse modelo de inspeção. A política precisa examinar o objeto montado antes de permitir execução, publicação ou consumo por um parser sensível.

Isso vale também para metadados. Nome, tipo, disposição e caminhos sugeridos são entradas não confiáveis. O processamento correto dos bytes não saneia o contexto em que serão usados. Continuidade e segurança são controles consecutivos, não propriedades intercambiáveis.

104 é apoio para retomar

O código interino 104 anuncia que há uma rota de retomada. Durante a criação pode informar a URI temporária e limites; durante o processamento pode expor o offset atual. O cliente que recebe essas coordenadas consegue sobreviver a uma queda posterior.

Ele não é a resposta final do recurso-alvo. Na estratégia otimista, o cliente começa enviando a representação inteira e espera obter 104 a tempo. Se a queda acontece antes, ou se um intermediário remove o interino, pode não haver caminho conhecido de retomada.

Na estratégia cuidadosa, o cliente cria primeiro um upload vazio, recebe a URI e então transmite. O custo de uma ida e volta compra previsibilidade. Nenhuma das estratégias autoriza uma tela a transformar “retomável” em “concluído”.

Deslocamentos divergentes exigem reconciliação

Cada anexo informa a visão do cliente sobre o offset. Se ela divergir do servidor, a resposta é 409 Conflict, com o offset atual e a indicação de conclusão. A barreira evita que uma resposta perdida ou um retry atrasado duplique dados.

O cliente deve reler estado, confirmar a identidade da fonte e escolher uma política explícita. Reenviar automaticamente a partir do cursor local pode repetir bytes que o servidor já processou. Aceitar sem comparação um cursor remoto associado a outra fonte pode corromper a montagem.

O protocolo não admite transferências paralelas para o mesmo recurso de upload. O servidor serializa anexos e cancelamento. Ainda assim, uma resposta final perdida exige consulta posterior e regras idempotentes na operação original.

A URI não é autorização eterna

A URI difícil de adivinhar reduz o risco de descoberta, e o servidor deve restringir acesso a clientes autorizados. Mas sigilo do identificador não é uma política completa. Ele pode vazar, sobreviver em logs ou permanecer utilizável depois que o papel do usuário mudou.

Uploads longos ampliam a distância entre checagem e uso. Quota, permissão, contrato e aprovação podem ser válidos na criação e inválidos na finalização. O draft recomenda verificar novamente privilégios e quotas antes de consumar a operação.

Assim, a cadeia de evidência tem degraus separados: entrega no transporte; prefixo processado; offset e comprimento reconciliados; conclusão explícita; digest e política de conteúdo; autorização vigente; commit pelo recurso-alvo; efeito posterior. O scanner ocupa um degrau próprio e deve ver a unidade que a aplicação efetivamente usará.

Fontes e limites

O conjunto congelado cobre a revisão 12 e seu histórico, o trabalho do grupo HTTP e os RFCs sobre semântica e versões HTTP, QUIC, Digest Fields, PATCH, Problem Details e Content-Disposition. As fontes descrevem mecanismos e riscos de desenho, não implementação, desempenho, incidente real, compatibilidade comprovada ou conduta de um fornecedor.

Fontes