Resumen

  • La norma de 2015 exige conservar separadas las partes con el mismo nombre y prohíbe que los intermediarios reordenen los resultados. Un mapa con un solo valor por campo puede borrar información que llegó correctamente.
  • El trabajo de Larry Masinter delimita responsabilidades: representar una entrega, interpretar sus datos y autorizar su tratamiento no son la misma operación.

El segundo archivo puede ser el dato decisivo. Supongamos que una solicitud admite dos documentos en un mismo campo. Ambos llegan como partes distintas con el mismo nombre, pero una función auxiliar entrega a la aplicación solo el último valor. No se ha demostrado un fallo de red: la pérdida ocurre al simplificar la representación. Este ejemplo es hipotético, no una denuncia sobre una biblioteca. Permite entender qué está en juego en la trayectoria de las especificaciones multipart asociadas a Larry Masinter.

Una solución que también debía convivir con el pasado

En noviembre de 1995, E. Nebel y L. Masinter firmaron el RFC 1867. Proponía que los formularios HTML pidieran archivos locales de manera uniforme, en lugar de obligar a cada servicio a desarrollar una aplicación propia. Combinaba selección de archivos, una representación compatible con MIME y una estrategia para navegadores antiguos. Su categoría era Experimental: el documento no se presentaba como una norma de Internet.

El RFC 2388, firmado por L. Masinter en agosto de 1998, pasó al Standards Track. En julio de 2015, el RFC 7578 sustituyó aquella especificación. Aunque conserva el nombre del autor, declara que expresa el consenso de la comunidad IETF tras revisión pública. La contribución personal debe leerse dentro de ese proceso y de los antecedentes MIME, no como la invención individual de todo el sistema de formularios. Su antigua página personal, fechada en 2014, aporta contexto histórico y una imagen de referencia, sin acreditar un empleo actual.

Multipart organiza el cuerpo en una serie de partes separadas por un delimitador. Cada una incluye una cabecera Content-Disposition de tipo form-data y un parámetro name que identifica el campo original. Así pueden viajar texto y archivos sin perder su separación. La norma de 2015 no se restringe a HTML, HTTP ni a procesos donde alguien rellena un formulario visible. Se ocupa de una representación que también utilizan otras aplicaciones y transportes.

Repetir no significa duplicar por error

La sección 5.5 del RFC 2388 no definía cómo relacionar el orden del formulario con el de los valores devueltos ni cómo tratar nombres de campo repetidos. El texto de 2015 precisa esos puntos. Los procesadores deberían devolver en orden los resultados de un formulario cuyo orden esté bien definido. Los intermediarios no deben reordenarlos, y las partes con nombres idénticos no deben fusionarse. La recomendación sobre el procesador no obliga a inventar un orden natural para formularios que no lo tienen.

Además, varias partes con el mismo nombre pueden ser la representación correcta. La sección 4.3 exige enviar varios archivos de un solo campo en partes separadas que compartan ese nombre. Desaconseja el anterior anidamiento multipart/mixed para ajustarse a la práctica ampliamente desplegada, pero recomienda que los receptores de uso general sigan admitiendo la modalidad antigua. Es una transición, no la ficción de que actualizar un documento actualiza automáticamente a todos los clientes.

El mapa de un solo valor puede ser una decisión válida después de comprobar la cantidad de elementos y aplicar un esquema explícito. Antes de ese examen, puede eliminar la prueba de que llegaron dos. Conservar una secuencia o varios valores por nombre mantiene esa posibilidad de revisión. No determina si la aplicación debe aceptar ambos: la multiplicidad del formato y la autorización de una acción pertenecen a planos distintos.

El nombre de archivo no es una orden de almacenamiento

Name vincula una parte con un campo; filename aporta otra información. El RFC 7578 recomienda un nombre para contenido de archivo, pero permite omitirlo si no está disponible, carece de sentido o es privado. El receptor no debe utilizarlo a ciegas ni conservar información de directorios como autoridad sobre el destino local. Un flujo procedente de un dispositivo no necesita un nombre inventado para parecer un archivo de escritorio.

La codificación tampoco admite una simplificación universal. La norma aconseja nombres de campo ASCII para facilitar la interoperabilidad, o UTF-8 uniforme cuando sean inevitables otros caracteres. Documenta convenciones de juego de caracteres predeterminado y reconoce diferentes comportamientos heredados. Prohíbe filename* en este formato; trasladar sin más una regla de otro contexto de cabeceras puede introducir una interpretación incorrecta.

Queda otra frontera: multipart no incluye un mecanismo propio que vincule el cuerpo con el formulario que lo originó. Ese contexto corresponde a la aplicación, por ejemplo mediante el destino de procesamiento o datos que ella incluya. Tampoco ofrece confidencialidad ni integridad. El RFC 1867 ya advertía que no debían enviarse archivos locales que el usuario no hubiera pedido transmitir. El RFC 7578 aborda divulgaciones involuntarias, sobrescrituras y contenido ejecutable. Que la sintaxis sea válida no resuelve esas responsabilidades.

Evidencia y alcance

Las fuentes son los tres RFC enlazados y la página personal fechada. No se presenta un censo de implementaciones, una auditoría de productos ni una frecuencia de incidentes. Las implicaciones operativas son análisis editorial. La foto pública de referencia fundamenta el retrato editorial generado con IA; el espacio de trabajo del fondo es imaginado, no una oficina documentada.