Resumo

  • RFC 1867 e RFC 2388 colocavam os arquivos de um único campo em uma parte multipart/mixed aninhada dentro de multipart/form-data.
  • RFC 7578 registrou que não havia emissores conhecidos para esse método, mudou para uma parte externa por arquivo com o mesmo nome de campo e preservou a compatibilidade para quem recebe a estrutura antiga.

O formulário precisava virar uma mensagem

Antes que navegadores pudessem enviar arquivos locais por um mecanismo comum de formulário, serviços muitas vezes dependiam de clientes feitos sob medida. Em 1995, a RFC 1867 propôs o controle HTML INPUT TYPE=FILE e uma representação MIME capaz de transportar campos comuns junto com o conteúdo dos arquivos. Era um documento Experimental, não uma norma Internet concluída; a proposta também considerava como conviver com agentes de usuário ainda incapazes de fazer upload.

O formato tinha duas camadas. multipart/form-data, por fora, identificava o campo. Se o usuário selecionasse vários arquivos naquele mesmo campo, uma parte multipart/mixed interna reuniria os arquivos. Era uma organização intuitiva no papel: uma camada para a relação com o formulário e outra para os itens da coleção.

Publicada em 1998 como Standards Track, a RFC 2388 tornou multipart/form-data independente de HTML e HTTP. Outras aplicações que devolvessem valores de um formulário também poderiam usá-la. Ainda assim, quando um campo representava vários arquivos, a especificação conservou a parte multipart/mixed aninhada. A forma descrita na proposta experimental passou para uma regra reutilizável.

O sucessor não encontrou quem enviasse daquele jeito

Em 2015, a RFC 7578 substituiu a RFC 2388 e registrou a diferença entre o modelo prescrito e os remetentes que seus autores conheciam. O uso aninhado deixou de ser recomendado para quem cria a mensagem e não se tornou uma exigência para todo receptor, porque não havia implementações emissoras conhecidas. Para corresponder às implementações observadas, cada arquivo passou a ocupar sua própria parte de primeiro nível. Arquivos do mesmo controle repetem o parâmetro name.

A associação mudou de lugar. Antes, uma parte nomeada continha uma lista interna de arquivos. Depois, a sequência externa traz partes paralelas que compartilham o nome do campo. A RFC 7578 não proibiu receber o formato antigo: recomenda que leitores voltados a usos gerais também o aceitem. A regra de envio foi atualizada; a leitura compatível continuou sendo útil.

“Não há implementações emissoras conhecidas” descreve o que os autores da RFC 7578 conseguiam identificar. Não prova que nenhum programa jamais emitiu a estrutura aninhada, nem revela participação de mercado, produto, data da mudança ou taxa de falhas. O fato histórico defensável é mais preciso: a revisão mudou o formato porque não conseguiu apontar implementações que enviassem a estrutura descrita pelo documento anterior.

Repetir o nome preserva valores distintos

A RFC 2388 também não definia a relação entre a ordem dos campos no formulário e a ordem das partes devolvidas, nem dizia como lidar com nomes repetidos. A RFC 7578 pede que uma ordem definida seja preservada, proíbe intermediários de reordenar os resultados e impede que partes com o mesmo nome sejam fundidas. Assim, um nome repetido pode significar vários valores do mesmo campo, e não uma colisão a ser eliminada.

Não houve abandono da estrutura MIME. As partes e suas fronteiras permaneceram; além disso, alguns formulários não têm uma ordenação natural. A mudança foi específica: para um controle de vários arquivos, usar partes irmãs e manter entre elas o mesmo nome de campo. A requisição, a ordem pretendida, os bytes enviados e a interpretação feita pela aplicação receptora continuam sendo fatos separados.

Código em funcionamento como evidência

No ensaio de Heng Lu sobre primazia do código em execução, a distinção central é entre o texto de um protocolo e o que sistemas realmente fazem. O caso da RFC 2388 é pequeno, mas claro: a RFC 7578 não preservou a recomendação anterior só por estar escrita. Ajustou a forma dos uploads múltiplos aos remetentes que os autores conseguiam documentar e manteve uma rota de compatibilidade para receptores.

O registro não informa quem propôs a correção, quantos sistemas estavam envolvidos ou quais custos operacionais pesaram na decisão. Não demonstra que implementadores sempre tenham razão, nem que um padrão deva apenas ratificar qualquer hábito. O aprendizado é mais limitado: descreva o formato, procure sistemas que de fato o enviem e, quando a regra mudar, pense em como os dados antigos serão lidos.

Fontes