html - etiqueta - method multipart form data
¿Cuál es el límite en multipart/form-data? (3)
Es el
???¿Libre de ser definido por el usuario?
Sí.
¿O es proporcionado por 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
El uso de application/x-www-form-urlencoded sería así:
name=John&age=12
Como puede ver, el servidor sabe que los parámetros están separados por un signo & . Si se requiere & para un valor de parámetro, debe codificarse.
Entonces, ¿cómo sabe el servidor dónde comienza y termina un valor de parámetro cuando recibe una solicitud HTTP utilizando 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 del límite es XXX . Usted lo especifica en el encabezado Content-Type para que el servidor sepa cómo dividir los datos que recibe.
Así que necesitas:
Utilice un valor que no aparecerá en los datos HTTP enviados al servidor.
Sea consistente y use el mismo valor en todas partes en el mensaje de solicitud.
Quiero hacer una pregunta sobre el multipart/form-data . En el encabezado HTTP, encuentro que el Content-Type: multipart/form-data; boundary=??? Content-Type: multipart/form-data; boundary=??? .
Es el ??? ¿Libre de ser definido por el usuario? ¿O es generalmente del HTML? ¿Es posible para mí definir el ??? = abcdefg ??? = abcdefg ?
La respuesta exacta a la pregunta es: sí, puede usar un valor arbitrario para el parámetro de boundary , dado que no supera los 70 bytes de longitud y consta solo de US-ASCII (imprimibles) de 7 bits de US-ASCII .
Si está utilizando uno de los tipos de contenido multipart/* , en realidad debe especificar el parámetro de boundary en el encabezado Content-Type ; de lo contrario, el servidor (en el caso de una solicitud HTTP) no podrá analizar la carga útil.
Probablemente también desee establecer el parámetro charset en UTF-8 en su encabezado Content-Type , a menos que pueda estar absolutamente seguro de que solo se usará el US-ASCII caracteres US-ASCII en los datos de la 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 se debe asumir en ausencia de un parámetro charset, es US-ASCII.
5.1. Multipart Media Type
Como se indica en la definición del campo de 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 7bit US-ASCII 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 una 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 delimitadora de límite se define entonces como una línea que consta completamente de dos guiones ("-", 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ímites no deben aparecer dentro del material encapsulado, y no deben tener más de 70 caracteres, sin contar los dos guiones principales.
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 otras 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 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 entre pares de nombre / valor separados. El límite actúa como un marcador de cada trozo de pares de nombre / valor que se pasa 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 Tipo de contenido: multipart / form-data; límite --- WebKit193844043-h (valor generado por el navegador ).
La carga útil aprobada 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 el formato @Consumes ("multipart / form-data").
Tenga en cuenta que al probar su servicio web utilizando Chrome Postman, 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 multipart / form-data arroja un error. Debido a que falta el límite, ya que anula la solicitud de curvatura de postman al servidor con tipo de contenido, agregando el límite que funciona bien.