Resumo

  • A RFC 1806 acrescentou inline, attachment e um filename opcional ao MIME para transmitir preferência de apresentação, sem afirmar que a apresentação ou a gravação ocorreu.
  • A recepção continuava responsável por remover caminhos, evitar colisões e impedir que nomes remotos criassem arquivos de inicialização, sobrescrevessem o sistema ou provocassem execução.
  • Quando Content-Disposition passou a respostas HTTP e partes de formulário, o sentido da comunicação se inverteu em alguns casos, mas a parte receptora continuou dona da ação local.

Um tipo de mídia não dizia onde o usuário encontraria a parte

A RFC 1521 deu ao correio da Internet a capacidade de carregar texto, imagens, dados de aplicações e estruturas multipartes. A organização foi refinada pelas RFC 2045 e RFC 2046. Um agente podia delimitar uma parte, desfazer sua codificação de transporte e ler o tipo declarado.

Nada disso determinava a próxima experiência. Uma imagem podia caber no fluxo de leitura ou exigir um visualizador externo. Uma planilha podia aparecer como ícone, item de menu ou linha num terminal. O remetente conhecia a função editorial da parte; o receptor conhecia o dispositivo, os programas disponíveis e o risco.

Publicada como Experimental em junho de 1995, a RFC 1806 propôs o campo opcional Content-Disposition para qualquer entidade MIME. Na ausência do campo, o agente de usuário permanecia livre para escolher o método de apresentação. O campo novo não produzia a autoridade do receptor nem a substituía: apenas acrescentava uma intenção remota à decisão local.

A disposição orientava o próximo gesto

inline indicava que a parte deveria normalmente aparecer no fluxo, sujeita às regras do contêiner multiparte. attachment adiava a apresentação até alguma ação adicional do usuário. A norma descrevia a separação, não uma interface obrigatória.

Esses valores eram prospectivos. inline não comprovava suporte ao formato, aprovação por uma política de segurança ou pixels efetivamente vistos. attachment não comprovava clique, salvamento ou abertura. Um registro do cabeçalho dizia o que foi pedido; outro evento teria de dizer o que ocorreu.

Uma disposição aplicada a um multiparte valia para o contêiner inteiro. Se o conjunto externo fosse anexo, suas partes internas só chegariam às próprias disposições depois que o primeiro limite fosse atravessado. A mensagem podia carregar vários portões encadeados. Observar o primeiro não provava que o último se abriu.

A RFC 1806 também definiu a postura diante do futuro: uma disposição desconhecida deveria ser tratada como attachment; parâmetros desconhecidos podiam ser ignorados. A extensão não ganhava exposição automática só porque o receptor ainda não compreendia seu nome.

O arquivo sugerido não era o arquivo criado

O parâmetro filename propunha um nome padrão caso o usuário decidisse destacar e arquivar a parte. Ele podia acompanhar até um item inline, sem qualquer gravação. Portanto, a presença desse parâmetro não era recibo de criação no sistema de arquivos.

O receptor deveria desprezar informações de diretório e adaptar o componente final às convenções locais. Deveria também impedir a substituição de um arquivo existente. Só o lado local sabe quais separadores têm efeito, quais nomes são reservados, quais diretórios são permitidos, quais extensões chamam programas e quais nomes já estão ocupados.

A seção de segurança enumerava ataques concretos: criar arquivo de inicialização, sobrescrever arquivo do sistema ou do usuário, depositar executável no caminho de comandos ou enviar dados a um pipe. A regra resultante era não permitir que nome e colocação remotos gerassem interpretação ou execução sem iniciativa explícita da pessoa.

Há uma cadeia verificável entre mensagem e efeito. Primeiro chega a cadeia bruta. Depois um parser reconhece o parâmetro. Uma política retira significado de caminho e resolve colisões. O sistema de arquivos grava sob um nome efetivo. Talvez outro aplicativo abra o conteúdo. Cada elo merece seu próprio registro; o primeiro não certifica os demais.

A revisão de 1997 acrescentou uma ficha, não um selo

O registro informativo da RFC 1806 mostra que a RFC 2183 a substituiu como Proposed Standard em agosto de 1997. A revisão manteve as disposições e o controle local do nome, acrescentando datas de criação, modificação e leitura e um tamanho aproximado.

Esses parâmetros faziam a parte parecer mais com um arquivo, mas continuavam sendo afirmações transportadas. A RFC 2183 alertou que st_ctime em Unix e POSIX não é hora de criação. O receptor podia preservar uma data, não inferir dela uma origem autenticada. O tamanho ajudava a estimar espaço, sem garantir alocação, integridade ou conclusão da escrita.

A revisão também criou um processo de registro de extensões. O atual registro Content Disposition da IANA mantém os valores originais e outros associados a protocolos específicos. Registro prova que há definição e referência; não prova implementação num cliente, nem equivalência entre posições de protocolo.

Um nome humano exigiu mais que ASCII

A gramática inicial restringia o nome sugerido ao US-ASCII. A RFC 2231 tratou valores longos, conjuntos de caracteres e indicação de idioma. Segmentos numerados podiam continuar um parâmetro; um asterisco marcava a forma estendida com charset, idioma opcional e octetos codificados por porcentagem.

O ganho de expressão trouxe estados intermediários: segmentos ausentes ou fora de ordem, mistura de partes codificadas e simples, charset desconhecido e sequência inválida. O nome Unicode final é resultado de seleção e decodificação. Para explicar uma falha, é preciso preservar também os componentes brutos.

Representação correta não equivale a permissão. Uma travessia de diretórios codificada de modo impecável continua sendo travessia. Um nome reservado em escrita local continua reservado. A RFC 2231 permitiu dizer melhor o nome; não permitiu escolher melhor o destino.

A Web usou primeiro e padronizou depois

Em 1999, a RFC 2616 registrou que Content-Disposition era implementado com frequência em HTTP, embora ainda não integrasse o padrão HTTP. Servidores já queriam pedir tratamento como download e oferecer uma denominação útil.

A RFC 6266 padronizou em 2011 o campo de resposta. O nome é apenas advisory. O agente deve impedir a escolha de local não autorizado, eliminar todos os componentes de caminho menos o último, desconfiar de extensões perigosas, remover controles e neutralizar nomes especiais ao sistema ou ao shell.

Uma resposta pode oferecer filename como compatibilidade e filename* para a forma estendida; quem entende ambos deve preferir a última. A RFC 8187 refinou a codificação de parâmetros HTTP e tornou obrigatório o suporte a UTF-8. Quando os valores divergem, a prioridade aplicada e o decodificador escolhido são parte do resultado, não detalhes descartáveis.

O formulário virou a seta

Nas partes multipart/form-data, Content-Disposition ocupa outra posição. A RFC 6266 exclui explicitamente esse uso corporal do seu perfil de resposta. A RFC 7578 exige form-data e um parâmetro name em cada parte; uma parte de arquivo deve trazer filename quando houver nome significativo.

Agora o navegador envia e a aplicação Web recebe. É a aplicação que precisa remover diretórios, adaptar convenções e decidir onde guardar. A RFC 7578 proíbe ainda filename* nessa posição, embora a resposta HTTP o utilize. O cabeçalho parece familiar, mas a gramática válida depende da direção e do contexto.

Essa inversão impede uma narrativa simplista de que o anexo de e-mail apenas virou o botão de download. O que atravessou os protocolos foi um contrato limitado: um participante remoto descreve a preferência e oferece um nome humano; o participante que recebe controla o efeito no próprio ambiente.

Fontes