multipart/form-data: cómo se estructura una subida de formulario en la red

Qué es

Una petición con Content-Type: multipart/form-data; boundary=xYz tiene un cuerpo como este:

--xYz
Content-Disposition: form-data; name="title"

Quarterly report
--xYz
Content-Disposition: form-data; name="file"; filename="q3.pdf"
Content-Type: application/pdf

%PDF-1.7 ...
--xYz--

RFC 7578 establece las reglas. Las partes se delimitan con CRLF, -- y el boundary, que NO DEBE aparecer dentro de ninguna parte. Cada parte DEBE incluir Content-Disposition: form-data con un name; un filename DEBERÍA acompañar al contenido de archivos, pero no debe usarse a ciegas, y cualquier información de directorio que contenga debe descartarse. Varios archivos para un mismo campo se envían como partes separadas con el mismo name; la forma anterior con multipart/mixed anidado está obsoleta, pero los analizadores deberían seguir aceptándola. El Content-Type de una parte es opcional y por defecto es text/plain; la codificación del texto procede de un parámetro charset o de un campo oculto _charset_. Content-Transfer-Encoding está obsoleto en HTTP y las demás cabeceras Content-* deben ignorarse. Las partes con el mismo nombre NO DEBEN fusionarse y se conserva el orden. Los nombres de archivo no ASCII pueden usar codificación porcentual, suelen enviarse como UTF-8 sin codificar, y la forma filename* de RFC 5987 NO DEBE usarse. El estándar HTML especifica cómo construyen los navegadores el cuerpo y cómo generan la cadena del boundary.

Por qué importa

A diferencia de application/x-www-form-urlencoded, cada parte puede declarar un tipo de medio y transportar bytes binarios sin la sobrecarga de un tercio de tamaño que supone base64 (cuatro bytes de salida por cada tres de entrada). Es el formato que producen todos los navegadores para <input type="file"> y el que aceptan la mayoría de las API de subida. Los analizadores que almacenan cuerpos completos en memoria, toman filename como una ruta o fusionan nombres repetidos son una fuente recurrente de errores y vulnerabilidades en las subidas.

Cómo aplicarlo

• Analiza en streaming: lee parte por parte, vuelca las partes de archivo a almacenamiento temporal y aplica límites de tamaño por parte y totales antes de consumir los datos.
• Identifica los campos por el parámetro name; trata filename como texto de visualización no confiable y genera tu propio nombre de almacenamiento.
• Considera el Content-Type de una parte como una pista y valida los bytes.
• En las API, documenta los nombres de campo, que pueden repetirse, y los límites; envía los metadatos JSON como una parte propia con Content-Type: application/json en lugar de ocultarlos en un campo de texto.
• En los clientes, deja que la biblioteca genere el boundary y Content-Length; no concatenes a mano.

Trampas

Evita los nombres de campo no ASCII; si son inevitables, RFC 7578 recomienda usar UTF-8 de forma uniforme. Los delimitadores son CRLF; un analizador que divide por LF suelto corrompe las partes binarias. Los frameworks que analizan multipart de forma anticipada en cada petición convierten las subidas grandes en una vía de denegación de servicio. El charset de las partes de texto suele estar ausente, así que hay que conocer el charset del formulario.