Resumen

  • RFC 1806 añadió a MIME inline, attachment y un filename opcional para comunicar preferencias, no para certificar que algo fue mostrado, abierto o escrito en disco.
  • La especificación exigía desechar información de directorio, impedir sobrescrituras y evitar nombres capaces de activar programas, tuberías o archivos de inicio sin una decisión local.
  • RFC 2183, RFC 2231, RFC 6266 y RFC 7578 adaptaron el campo a más metadatos, alfabetos y contextos; ninguna convirtió el nombre transmitido en una ruta autorizada.

El contenedor llegó antes que la instrucción de presentación

RFC 1521 convirtió el correo de Internet en un contenedor capaz de transportar varias clases de contenido. RFC 2045 y RFC 2046 consolidaron después la sintaxis MIME y sus tipos multipartes. Era posible separar las partes, decodificarlas y saber qué tipo afirmaba tener cada una.

Faltaba otra clase de información. El remitente podía considerar que una imagen formaba parte de la lectura continua, mientras que una hoja de cálculo debía permanecer cerrada hasta que el destinatario decidiera abrirla. El tipo de medio no expresaba esa diferencia y tampoco podía anticipar las posibilidades de cada interfaz.

En junio de 1995, la experimental RFC 1806 propuso el campo opcional Content-Disposition para cualquier entidad MIME. Si el campo faltaba, el agente de usuario conservaba plena libertad para presentar la parte como estimara conveniente. Esa regla de ausencia importa: la nueva señal se incorporaba a la decisión del receptor, no reemplazaba la decisión.

inline y attachment describían el próximo umbral

La disposición inline indicaba que la parte debía mostrarse automáticamente dentro del flujo normal, siempre subordinada a las reglas del multiparte que la contenía. attachment pedía una acción adicional del usuario. Un cliente gráfico podía dibujar un icono; un terminal podía ofrecer una lista. El estándar no confundía la intención con una interfaz concreta.

Tampoco confundía la etiqueta con un resultado. Que una parte diga inline no demuestra que el receptor conozca el formato, supere sus controles o llegue a mostrarla. Que diga attachment no demuestra que alguien la haya guardado. El campo es una afirmación sobre el tratamiento deseado, no un recibo de interacción humana.

Las disposiciones de entidades anidadas operaban por niveles. Una disposición aplicada a un contenedor multiparte gobernaba la presentación del contenedor. Solo después de abrirlo podían entrar en juego las disposiciones internas. Por ello, una captura del sobre exterior no demuestra que el usuario alcanzara la parte interior.

Para tipos desconocidos, RFC 1806 eligió un repliegue conservador: tratarlos como adjuntos. La novedad sintáctica no obtenía permiso para la exposición automática. Los parámetros desconocidos podían ignorarse. Era una compatibilidad que limitaba efectos, no una licencia para adivinar intenciones.

La última componente no era la ruta recibida

filename ofrecía un nombre predeterminado si el destinatario decidía separar una parte y archivarla. El propio texto lo presentaba como una sugerencia. Podía aparecer incluso en una parte inline; en ese caso quizá nunca hubiese una operación de escritura.

Una ruta no es un nombre universal. Los sistemas asignan sentidos distintos a barras, puntos, letras de unidad, caracteres de control, extensiones y nombres reservados. El remitente desconoce qué archivos existen, qué carpetas son escribibles y qué asociación puede convertir una extensión en ejecución.

RFC 1806 ordenaba ignorar la información de directorio incluida en el valor y conservar, como máximo, una componente terminal adaptada a las convenciones locales. También exigía evitar la sobrescritura de un archivo existente. Así, ../../inicio, una ruta absoluta o una secuencia válida en otro sistema no se convertían por su mera llegada en una ubicación legítima.

La advertencia de seguridad era específica: un nombre malicioso podía crear un archivo de arranque, reemplazar un archivo del sistema, destruir uno existente, depositar un ejecutable en la ruta de búsqueda de comandos o dirigir contenido a una tubería. La defensa no consistía en creer mejor al campo, sino en impedir que nombre y ubicación causaran interpretación o ejecución sin iniciativa explícita de la persona.

Por eso conviene conservar recibos separados. El valor bruto prueba qué cadena llegó. El análisis prueba cómo la entendió una versión concreta del software. El saneamiento explica qué significado de ruta se eliminó. Solo la operación del sistema de archivos prueba el nombre y lugar efectivos. Y solo una observación posterior puede probar que los bytes fueron abiertos o ejecutados.

Más atributos no convirtieron el mensaje en notario

La ficha histórica de RFC 1806 señala que RFC 2183 la sustituyó en agosto de 1997 como Proposed Standard. La revisión retuvo inline, attachment y las comprobaciones locales del nombre. Añadió fechas de creación, modificación y lectura y un tamaño aproximado.

Esos campos facilitaban decisiones y presentación, pero no autenticaban la historia del archivo. RFC 2183 advertía que st_ctime en Unix y POSIX no es la hora de creación. Una fecha seguía siendo una afirmación del remitente que el receptor podía decidir preservar. El tamaño podía servir para estimar espacio, pero no era un hash, una garantía de reserva ni un recibo de escritura completa.

RFC 2183 también estableció procedimientos de registro. El registro de Content Disposition de IANA conserva las disposiciones y parámetros definidos a lo largo del tiempo. Un token registrado tiene una referencia pública; eso no demuestra que esté implementado en un cliente particular ni que tenga el mismo sentido en todos los contextos donde aparece el nombre del campo.

Los alfabetos humanos exigieron reconstrucción

RFC 1806 reconocía que su gramática dejaba filename limitado a US-ASCII. RFC 2231 introdujo continuaciones numeradas para valores largos y una forma extendida con juego de caracteres, idioma opcional y octetos codificados con porcentajes.

La mejora hizo posible transportar nombres legibles en muchas escrituras, pero también añadió decisiones del parser. Hay que ordenar segmentos, detectar huecos, distinguir secciones codificadas y sin codificar, interpretar el juego de caracteres y conservar los errores. El texto Unicode final es un producto de esa reconstrucción. No debería borrar la evidencia del valor original.

La codificación tampoco sanea. Si una secuencia internacional reconstruye una ruta transversal o un nombre reservado, el peligro continúa intacto. RFC 2231 resolvía representación y longitud; no otorgaba al emisor derechos sobre el espacio de nombres receptor.

HTTP adoptó el campo antes de reconocerlo como propio

RFC 2616 observó en 1999 que Content-Disposition se implementaba con frecuencia en HTTP, aunque entonces no pertenecía al estándar HTTP. La práctica trasladó el contrato desde el correo: un servidor quería separar una representación de la vista normal y ofrecer un nombre de descarga.

En 2011, RFC 6266 definió formalmente el campo de respuesta. Su lenguaje es inequívoco: los nombres son solo orientativos. El agente debe eliminar todas las componentes de ruta salvo la última, impedir ubicaciones no autorizadas, desconfiar de extensiones peligrosas, quitar caracteres de control y neutralizar nombres con significado especial para el sistema o la shell.

Para nombres internacionales, una respuesta puede ofrecer un filename compatible y un filename* extendido; un receptor que entienda ambos debe preferir el segundo. RFC 8187 refinó la forma extendida de HTTP y exigió UTF-8. La selección sigue siendo una decisión observable: ambos valores pueden no coincidir y el nombre mostrado depende del soporte real del cliente.

En la subida, el navegador pasó a ser el remitente

Content-Disposition también encabeza las partes de un formulario, pero no es el mismo uso. RFC 6266 excluye los campos internos de multipart/form-data de su perfil de respuesta. RFC 7578 exige form-data y un parámetro name en cada parte, y recomienda filename para una parte de archivo cuando existe un nombre significativo.

Ahora el navegador envía y la aplicación Web recibe. La aplicación debe desechar el camino, adaptar el nombre y decidir dónde almacenar. RFC 7578, además, prohíbe filename* para este contexto corporal aunque la respuesta HTTP lo utilice. Aplicar correctamente la gramática de descarga a una subida seguiría siendo interpretar el contrato equivocado.

La continuidad histórica está en la frontera, no en una sintaxis idéntica. Por correo, descarga o formulario, una parte remota puede declarar una preferencia y proponer una etiqueta humana. El sistema que asume el coste de una colisión, una ejecución o una pérdida conserva la ruta final.

Fuentes