Resumo

  • A revisão de 2015 proíbe juntar partes com o mesmo nome e reordenar resultados nos intermediários. Uma solicitação bem recebida ainda pode perder valores dentro da aplicação.
  • O percurso das especificações de Larry Masinter separa a fidelidade da representação, a interpretação de negócio e a autorização para tratar um arquivo.

Simplificar dados pode deslocar uma decisão sem que ninguém perceba. Imagine um cadastro que recebe dois comprovantes no mesmo campo de envio. Cada arquivo chega em uma parte própria, com o mesmo nome de campo. Uma função converte o conjunto em um mapa que guarda apenas o último valor. O transporte pode ter preservado tudo; o cadastro, não. Este é um exemplo de mecanismo, não um incidente documentado nem uma acusação contra alguma biblioteca. Ele ajuda a ler a contribuição de Larry Masinter para multipart como uma questão de responsabilidade sobre a informação, e não apenas de conveniência para anexar arquivos.

O passado que uma revisão não elimina

O RFC 1867, de novembro de 1995, foi escrito por E. Nebel e L. Masinter. A proposta respondia à falta de uma maneira uniforme de formulários HTML pedirem arquivos locais, situação que levava serviços a criar aplicações próprias. Reunia seleção de arquivo, representação compatível com MIME e uma estratégia para navegadores antigos. Sua categoria era Experimental: o texto não se dizia um padrão da Internet.

Em agosto de 1998, o RFC 2388, assinado por L. Masinter, entrou no Standards Track. O RFC 7578, de julho de 2015, o substituiu. O nome do autor permanece, mas o documento registra consenso da comunidade IETF após revisão pública. Não cabe atribuir a uma única pessoa todos os fundamentos MIME ou todas as práticas dos navegadores. A página pessoal antiga de Masinter, com referência temporal de 2014, oferece contexto histórico e uma foto pública; não comprova seu emprego atual.

Multipart organiza o corpo em uma série de partes separadas por um delimitador. Cada parte tem Content-Disposition do tipo form-data e um parâmetro name que aponta para o campo original. Texto e conteúdo de arquivos podem viajar juntos sem se tornarem indistintos. A especificação de 2015 vai além de HTML e HTTP, incluindo aplicações em que ninguém preenche um formulário visível. O botão de envio é apenas uma manifestação dessa representação.

Quando repetir é representar corretamente

A seção 5.5 do texto de 1998 deixava indefinidas a relação entre a ordem dos campos e a ordem dos valores retornados e a forma de tratar nomes repetidos. A seção 5.2 da revisão de 2015 estabeleceu uma fronteira mais clara. Processadores de formulários com ordem bem definida deveriam devolver resultados nessa ordem. Intermediários não podem reordená-los, e partes de mesmo nome não podem ser fundidas. A primeira regra é uma recomendação normativa, não uma obrigação de inventar ordem para todo formulário.

Para vários arquivos de um só campo, a repetição faz parte do formato correto: a seção 4.3 exige partes separadas com o mesmo name. O antigo arranjo aninhado multipart/mixed foi descontinuado em favor da prática amplamente utilizada. Ainda assim, a especificação recomenda que receptores de uso amplo aceitem também o método antigo. Trata-se de administrar uma transição, não de declarar que todos os clientes foram atualizados ao mesmo tempo.

Um mapa de valor único pode ser adequado depois que a aplicação verifica a quantidade de elementos e escolhe uma interpretação explícita. Antes disso, a conversão pode eliminar a evidência de que chegaram dois. Uma sequência ou estrutura de múltiplos valores mantém a possibilidade de análise. Isso não obriga a aceitar ambos como instruções legítimas. Preservar a representação e autorizar uma ação são tarefas diferentes.

Metadados não mandam no armazenamento

O nome do campo identifica sua posição na submissão. Filename informa outra coisa. O RFC 7578 recomenda fornecer um nome para conteúdo de arquivo, mas admite que ele falte quando indisponível, sem significado ou privado. O receptor não deve usá-lo cegamente nem transformar informações de diretório em instruções para o destino local. Um fluxo produzido diretamente por um dispositivo não precisa receber um nome fictício de arquivo de computador.

O tratamento de caracteres também carrega decisões de compatibilidade. O texto recomenda nomes de campo ASCII para interoperabilidade ampla, ou UTF-8 uniforme quando outros caracteres forem inevitáveis. Documenta convenções de conjunto de caracteres padrão e reconhece diferenças entre geradores antigos. Proíbe filename* nesse formato, mostrando por que uma regra de outro contexto de cabeçalho não deve ser transplantada automaticamente.

Há ainda uma ausência deliberada: multipart não fornece um mecanismo próprio de ligação entre o corpo e o formulário que o originou. O contexto depende da aplicação, por exemplo do destino de processamento ou dos dados que ela inclua. O formato tampouco oferece confidencialidade ou integridade. O texto de 1995 já alertava contra transmitir arquivos locais que o usuário não tivesse pedido explicitamente para enviar. A revisão de 2015 discute divulgação involuntária, sobrescrita de arquivos e conteúdo executável. Ler a estrutura com sucesso não resolve essas decisões de confiança.

Fontes e limites

A análise compara os três RFCs citados e a página pessoal datada. Não inclui levantamento de implementações atuais, taxa de perda, auditoria de bibliotecas ou teste de ataque. As implicações operacionais são deduções editoriais. A foto de referência pública fundamenta a identidade do retrato editorial produzido por IA; o ambiente de trabalho no fundo é inventado, não uma instalação real comprovada.