¿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 Content-Type: multipart/form-data; boundary=???.

¿El ???usuario puede definir la libertad? ¿O se genera a partir del HTML? ¿Es posible para mí definir el ??? = abcdefg?

¿El ???usuario puede definir la libertad?

Si.

o es suministrado por el HTML?

No. HTML no tiene nada que ver con eso. Lee abajo.

¿Es posible para mí definir el ???como abcdefg?

Si.

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 ampersand &. Si &se requiere para un valor de parámetro, debe estar codificado.

Entonces, ¿cómo sabe el servidor dónde comienza y termina un valor de parámetro cuando recibe una solicitud HTTP 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 especifica en el Content-Typeencabezado para que el servidor sepa cómo dividir los datos que recibe.

Entonces necesitas:

• Use un valor que no aparecerá en los datos HTTP enviados al servidor.

• Sea coherente y use el mismo valor en todas partes en el mensaje de solicitud.

La respuesta exacta a la pregunta es: sí, puede usar un valor arbitrario para el boundaryparámetro , dado que no supera los 70 bytes de longitud y consta solo de caracteres de 7 bitsUS-ASCII (imprimibles).

Si está utilizando uno de los multipart/*tipos de contenido, en realidad debe especificar el boundaryparámetro en el Content-Typeencabezado; de lo contrario, el servidor (en el caso de una solicitud HTTP) no podrá analizar la carga útil.

Probablemente también desee establecer el charsetparámetro UTF-8en su Content-Typeencabezado, a menos que pueda estar absolutamente seguro de que solo se US-ASCIIusará charset en los datos de carga útil.

Algunos extractos relevantes del RFC2046 :

• 4.1.2. Parámetro Charset:

  A diferencia de otros valores de parámetros, los valores del parámetro charset NO distinguen entre mayúsculas y minúsculas. El conjunto de caracteres predeterminado, que debe asumirse 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 Codificación de transferencia de contenido [RFC 2045], no se permite ninguna codificación que no sea "7 bits", "8 bits" o "binario" para entidades de tipo "multiparte". Los delimitadores de límite "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 no US-ASCII según RFC 2047) y los datos dentro de las partes del cuerpo pueden codificarse 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 multiparte requiere un parámetro, "límite". La línea delimitador de límite se define como una línea que consta completamente de dos caracteres de guión ("-", valor decimal 45) seguido del valor del parámetro de límite del campo de encabezado Content-Type, espacio en blanco lineal opcional y un CRLF de terminación.

  Los delimitadores de límite 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 delimitador 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. Tal 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 límite.

Aquí hay un ejemplo usando un límite arbitrario:

Content-Type: multipart/form-data; charset=utf-8; boundary="another cool boundary"

--another cool boundary
Content-Disposition: form-data; name="foo"

bar
--another cool boundary
Content-Disposition: form-data; name="baz"

quux
--another cool boundary--

multipart / form-data contiene límites para separar pares de nombre / valor. El límite actúa como un marcador de cada porción 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 forma @Consumes ("multipart / form-data").

Tenga cuidado, cuando pruebe su servicio web utilizando el cartero de Chrome, debe verificar 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 multiparte / formulario arroja un error. Debido a que falta el límite, ya que anula la solicitud de curl de post man al servidor con tipo de contenido agregando el límite que funciona bien.

Ver RFC1341 sec7.2 El tipo de contenido multiparte