Resumo

  • A RFC 2231 numera partes desde zero, exige sequência contínua e coloca conjunto de caracteres e idioma opcional somente no começo da primeira parte codificada. A ordem dos índices, não a posição no cabeçalho, determina a remontagem.
  • Mesmo válido, filename é uma sugestão de Content-Disposition. A RFC 2183 manda ignorar caminhos, evitar sobrescrita e destinos perigosos e impedir execução sem iniciativa explícita do usuário.

A fronteira pode cortar um caractere

Considere este exemplo feito apenas para explicar o mecanismo:

filename*0*=utf-8'en'Quarterly%20; filename*1*=review%20; filename*2=final.pdf

As três linhas pertencem a um único parâmetro. A primeira declara UTF-8, inclui idioma opcional e inicia o valor; a segunda continua com bytes escapados; a terceira fecha sem marca de codificação. Com 0, 1 e 2 completos e inequívocos, o resultado lógico é Quarterly review final.pdf.

O receptor não pode confiar na ordem em que as linhas aparecem. Parâmetros MIME podem ser reordenados, portanto *2 pode anteceder *0. A RFC 2231 exige início em zero, incremento unitário, nenhum buraco e nenhum zero à esquerda. O programa deve agrupar pelo nome-base, detectar repetições ambíguas, validar a série e concatenar pelas etiquetas numéricas.

Só depois vem a decodificação. Conjunto de caracteres e idioma são declarados uma vez no início, não em cada fragmento. A divisão em partes atende ao transporte e pode atravessar os bytes de um caractere UTF-8. Se cada trecho for convertido em texto isoladamente, dois produtos podem inserir caracteres de substituição ou chegar a nomes diferentes.

Uma cadeia prudente separa operações: analisar nomes; validar uma série única; ordenar e unir a carga; transformar escapes de porcentagem em octetos; interpretar o conjunto declarado; então entregar o texto a uma política de disposição. A seção de segurança da RFC 2231 é breve, mas a gramática e a declaração inicial única sustentam essa ordem. Remontar prova estrutura; decodificar prova uma interpretação; nenhuma etapa prova confiança.

Metadado não é comando de sistema

A RFC 2231 ampliou a maneira de escrever um valor. Não deu ao emissor remoto poder sobre o armazenamento local. A RFC 2183, que define Content-Disposition, chama filename de nome sugerido para salvar uma parte separada da mensagem.

O agente receptor não deve adotá-lo às cegas. Informações de diretório devem ser descartadas, preservando no máximo o componente final. É preciso impedir sobrescritas, escrita em áreas de sistema ou inicialização, uso de arquivos especiais e pipes, e colocação de executáveis em caminhos de busca. O arquivo não deve ser nomeado ou posicionado de modo que rode sem uma ação explícita.

Uma sequência UTF-8 perfeitamente formada ainda pode conter ../, caminho absoluto, controles invisíveis, marcas bidirecionais, nomes reservados ou extensão enganosa. Decodificar %HH não higieniza. Um charset válido não autentica remetente. Concordância entre nome e Content-Type não garante o conteúdo. E nenhum desses sinais concede permissão de salvar, substituir, abrir, executar ou atribuir.

O desenho correto mantém as responsabilidades apartadas. O parser MIME julga a coerência da continuação. O decodificador produz texto. Uma regra local escolhe ou cria um nome seguro. A camada de armazenamento confina o destino e resolve colisões. Usuário ou política autorizada decide se o conteúdo pode ser aberto. Um portão aprovado não substitui o seguinte.

Autoria também tem uma sequência verificável

A RFC 2231 foi assinada por Ned Freed e Keith Moore. Sua antecessora, RFC 2184, também traz os dois nomes. Esse é o limite documental da coautoria do mecanismo.

Patrik Fältström ocupa lugar importante na internacionalização da Internet, mas não é autor da RFC 2231 nem da RFC 2184. A RFC 3490, antiga especificação de IDNA, foi assinada por Fältström, Paul Hoffman e Adam Costello. Misturar contribuições vizinhas cria uma relação que as fontes não sustentam. Tema próximo não significa mesmo documento, mesma equipe ou mesmo contrato.

O IETF Datatracker registra a obra ampla de Freed em correio e tipos de mídia. No memorial, Nathaniel Borenstein descreve como a busca por mensagens mais ricas encontrou a atenção de Freed à robustez e interoperabilidade. A RFC 2045 organiza corpos MIME; a RFC 2047 trata texto não ASCII em cabeçalhos; a RFC 2231 resolve o problema mais estreito dos parâmetros.

Esse recorte evita generalização. Um asterisco não dá automaticamente a qualquer campo a semântica da RFC 2231; a especificação que define o campo precisa adotá-la. Transportar caracteres internacionais também não torna o valor uma declaração de identidade.

O perfil HTTP ficou deliberadamente menor

A RFC 8187 levou ao HTTP uma forma relacionada de parâmetro codificado, tornou UTF-8 obrigatório e excluiu as continuidades da RFC 2231 porque o HTTP não precisava delas. A linhagem foi preservada sem copiar toda a superfície.

A RFC 6266 reforça a fronteira no Content-Disposition HTTP: filename é consultivo. O destinatário remove partes de caminho, controla o diretório, neutraliza extensões perigosas, caracteres de controle e nomes especiais. Um servidor sugere um rótulo; não recebe autoridade sobre o sistema de arquivos do cliente.

A herança da RFC 2231 é a precisão em duas direções. Interoperabilidade exige numeração contínua, uma declaração inicial e ordem determinística de remontagem. Segurança exige dizer com a mesma precisão o que isso não comprova. Um valor recuperado pode ser inteligível e continuar não confiável.

Fontes