Resumen

  • RFC 1867 y RFC 2388 representaron varios archivos de un mismo campo mediante una parte multipart/mixed anidada dentro de multipart/form-data.
  • RFC 7578 señaló que no se conocían emisores que implementaran esa forma; pasó a una parte exterior por archivo, repitió el nombre del campo y conservó compatibilidad de recepción con el formato anterior.

Un control nuevo exigía una forma de viajar

Antes de que los formularios del navegador pudieran enviar archivos locales mediante un mecanismo común, a menudo hacía falta una aplicación cliente específica. RFC 1867, publicado en 1995 como Experimental, propuso INPUT TYPE=FILE y una representación MIME que mezclaba campos ordinarios con contenido de archivos. No se presentaba como norma de Internet definitiva. Incluso contemplaba una transición para agentes de usuario que aún no supieran cargar archivos.

El formato separaba dos cosas. La parte exterior multipart/form-data identificaba el campo del formulario; si el usuario elegía varios archivos en ese campo, una parte interior multipart/mixed contenía los archivos. El dibujo funcionaba como una estructura coherente: una parte representaba el control, otra su colección de ficheros.

RFC 2388, de 1998 y Standards Track, definió multipart/form-data para que pudiera usarse fuera de HTML y HTTP, por ejemplo en otras aplicaciones con formularios. Pero mantuvo la parte multipart/mixed interior cuando un campo representaba varios archivos. El esquema del experimento pasó a formar parte de una especificación reutilizable, y con él viajó una decisión concreta de formato.

La revisión no encontró emisores para aquella estructura

RFC 7578 sustituyó a RFC 2388 en 2015 y dejó constancia explícita de una discrepancia. Ya no recomendó a quienes generan formularios que aniden multipart/mixed, ni exigió a todos los receptores que procesaran esa forma: sus autores no conocían emisores que la implementaran. Para ajustarse a las implementaciones conocidas, cada archivo debía ocupar una parte exterior propia; las partes que correspondieran al mismo control repetirían el parámetro name.

El agrupamiento cambió de lugar. Antes, una parte con nombre contenía una lista MIME interna. Después, varias partes hermanas llevaban el mismo nombre de campo. RFC 7578 no declaró imposible ni inválido recibir la estructura antigua; recomendó que los receptores destinados a un uso amplio también la admitieran. Cambió la regla para emitir, pero dejó una senda de lectura compatible.

La frase “no se conocen implementaciones emisoras” describe el estado de conocimiento registrado por RFC 7578, no prueba que ningún programa enviara nunca la estructura anidada. No identifica navegador, servidor, cuota de mercado, fecha de cambio ni tasa de fallos. Lo que sí respalda es más acotado: la especificación corrigió una forma de datos porque los autores de la revisión no podían señalar implementaciones que la produjeran.

Repetir un nombre no era fusionar valores

RFC 2388 había dejado sin definir si el orden de las partes devueltas debía seguir el del formulario y qué significaba repetir un nombre de campo. RFC 7578 pide conservar el orden cuando el formulario lo establece, prohíbe que intermediarios reordenen los resultados y prohíbe fusionar partes con nombres idénticos. Así, varios valores pueden permanecer asociados a un campo sin convertirse en una colisión de claves.

No fue una sustitución general de MIME por una secuencia sin estructura. MIME siguió delimitando las partes, y algunos formularios no tienen un orden natural. La corrección trató un caso concreto: un control de varios archivos aparece como varias partes al mismo nivel, unidas por el nombre de campo común. La solicitud completa, el orden previsto, los bytes de cada parte y la interpretación de la aplicación receptora siguen siendo evidencias distintas.

El código en funcionamiento como evidencia

Heng Lu, en su texto sobre la primacía del código en ejecución, pide no confundir el protocolo escrito con el comportamiento desplegado. RFC 2388 permite observar esa diferencia sin extrapolarla: RFC 7578 no conservó intacta una recomendación anterior solo por haber sido publicada. Sus autores ajustaron la representación de varios archivos a los emisores que podían documentar y conservaron compatibilidad para los receptores.

El expediente no dice quién impulsó el cambio, cuántos programas estaban implicados ni qué costes operativos pesaron en la decisión. Tampoco demuestra que los implementadores siempre tengan razón o que la norma deba ratificar cualquier hábito de software. La conclusión prudente es metodológica: describir una forma de datos, buscar sistemas que realmente la emitan y preparar la lectura de datos antiguos cuando el estándar cambia.

Fuentes