¿Cuál es el límite en multipart/form-data?
Quiero hacer una pregunta sobre el multipart/form-data. En el encabezado HTTP, encuentro que el archivo Content-Type: multipart/form-data; boundary=???.
¿La ???libertad la define el usuario? ¿O se genera a partir del HTML? ¿Es posible para mí definir el ??? = abcdefg?
¿La
???libertad la define el usuario?
Sí.
¿O lo proporciona el HTML?
No. HTML no tiene nada que ver con eso. Lee abajo.
¿Es posible para mí definir el
???comoabcdefg?
Sí.
Si desea enviar los siguientes datos al servidor web:
name = John
age = 12
usar application/x-www-form-urlencodedsería así:
name=John&age=12
Como puede ver, el servidor sabe que los parámetros están separados por un signo comercial &. Si &es necesario para un valor de parámetro, debe codificarse.
Entonces, ¿cómo sabe el servidor dónde comienza y termina el valor de un parámetro cuando recibe una solicitud HTTP mediante multipart/form-data?
Usando el límite , similar a &.
Por ejemplo:
--XXX
Content-Disposition: form-data; name="name"
John
--XXX
Content-Disposition: form-data; name="age"
12
--XXX--
En ese caso, el valor límite es XXX. Lo especificas en el Content-Typeencabezado para que el servidor sepa cómo dividir los datos que recibe.
Entonces necesitas:
Utilice un valor que no aparezca en los datos HTTP enviados al servidor.
Sea coherente y utilice el mismo valor en todas partes del mensaje de solicitud.
La respuesta al fondo de la pregunta es sí . Puede utilizar un valor arbitrario para el boundaryparámetro siempre que tenga menos de 70 bytes y solo contenga caracteres de 7 bitsUS-ASCII (imprimibles).
Si utiliza uno de multipart/*los tipos de contenido, en realidad deberá especificar el boundaryparámetro en el Content-Typeencabezado. De lo contrario, en el caso de una solicitud HTTP, el servidor no podrá analizar la carga útil.
A menos que esté absolutamente seguro de que solo US-ASCIIse utilizará el conjunto de caracteres en su carga útil, es posible que desee agregar un Content-Typeencabezado a cada parte, con el charsetparámetro establecido en UTF-8.
Algunos extractos relevantes del RFC2046 :
4.1. Tipo de medio de texto
Se puede utilizar un parámetro "charset" para indicar el juego de caracteres del cuerpo del texto para los subtipos de "texto", incluido en particular el subtipo "text/plain", que es un subtipo genérico para texto sin formato.
4.1.2. Parámetro del juego de caracteres
Un parámetro crítico que se puede especificar en el campo Tipo de contenido para datos "texto/sin formato" es el juego de caracteres.
A diferencia de otros valores de parámetros, los valores del parámetro charset NO distinguen entre mayúsculas y minúsculas. El juego de caracteres predeterminado, que se debe asumir en ausencia de un parámetro de juego de caracteres, es US-ASCII.
5.1. Tipo de medio multiparte
Como se indica en la definición del campo Content-Transfer-Encoding [RFC 2045], no se permite ninguna codificación distinta de "7 bits", "8 bits" o "binaria" para entidades de tipo "multiparte". Los delimitadores de límites "multiparte" y los campos de encabezado siempre se representan como US-ASCII de 7 bits en cualquier caso (aunque los campos de encabezado pueden codificar texto de encabezado que no sea US-ASCII según RFC 2047) y los datos dentro de las partes del cuerpo se pueden codificar en un parte por parte, con campos de codificación de transferencia de contenido para cada parte del cuerpo apropiada.
El campo Tipo de contenido para entidades de varias partes requiere un parámetro, "límite". Luego, la línea delimitadora de límites se define como una línea que consta enteramente de dos caracteres de guión ("-", valor decimal 45) seguidos por el valor del parámetro de límite del campo de encabezado Tipo de contenido, un espacio en blanco lineal opcional y un CRLF final.
Los delimitadores de límites no deben aparecer dentro del material encapsulado y no deben tener más de 70 caracteres, sin contar los dos guiones iniciales.
La línea delimitadora de límite que sigue a la última parte del cuerpo es un delimitador distinguido que indica que no seguirán más partes del cuerpo. Dicha línea delimitadora es idéntica a las líneas delimitadoras anteriores, con la adición de dos guiones más después del valor del parámetro de límite.
A continuación se muestra un ejemplo que utiliza un límite arbitrario:
Content-Type: multipart/form-data; boundary="yet another boundary"
--yet another boundary
Content-Disposition: form-data; name="foo"
bar
--yet another boundary
Content-Disposition: form-data; name="baz"
quux
--yet another boundary
Content-Disposition: form-data; name="feels"
Content-Type: text/plain; charset=utf-8
🤷
--yet another boundary--
multipart/form-data contiene límites para separar pares de nombre/valor. El límite actúa como un marcador de cada fragmento de pares de nombre/valor pasados cuando se envía un formulario. El límite se agrega automáticamente a un tipo de contenido de un encabezado de solicitud.
El formulario con el atributo enctype="multipart/form-data" tendrá un encabezado de solicitud Content-Type : multipart/form-data; límite --- WebKit193844043-h ( valor generado por el navegador ).
La carga útil pasada se parece a esto:
Content-Type: multipart/form-data; boundary=---WebKitFormBoundary7MA4YWxkTrZu0gW
-----WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name=”file”; filename=”captcha”
Content-Type:
-----WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name=”action”
submit
-----WebKitFormBoundary7MA4YWxkTrZu0gW--
En el lado del servicio web, se consume en formato @Consumes("multipart/form-data").
Tenga cuidado, al probar su servicio web con Chrome Postman, debe marcar la opción de datos del formulario (botón de opción) y el menú Archivo en el cuadro desplegable para enviar el archivo adjunto. La provisión explícita de tipo de contenido como datos de formulario/multiparte genera un error. Porque falta el límite, ya que anula la solicitud curl del postman al servidor con el tipo de contenido agregando el límite, lo cual funciona bien.
Consulte RFC1341 sección 7.2 El tipo de contenido multiparte
