Quelle est la limite dans multipart / form-data?

Je veux poser une question sur les multipart/form-data . Dans l’en-tête HTTP, je trouve que le type de Content-Type: multipart/form-data; boundary=??? Content-Type: multipart/form-data; boundary=??? .

Est le ??? libre d’être défini par l’utilisateur? Ou c’est généralement du HTML? Est-il possible pour moi de définir le ??? = abcdefg ??? = abcdefg ?

Est le ??? libre d’être défini par l’utilisateur?

Oui.

ou est-il fourni par le HTML?

Non, HTML n’a rien à voir avec ça. Lire ci-dessous.

Est-il possible pour moi de définir le ??? comme abcdefg ?

Oui.

Si vous souhaitez envoyer les données suivantes au serveur Web:

 name = John age = 12 

utiliser application/x-www-form-urlencoded serait comme ceci:

 name=John&age=12 

Comme vous pouvez le voir, le serveur sait que les parameters sont séparés par une esperluette & . Si & est requirejs pour une valeur de paramètre, il doit être codé.

Alors, comment le serveur sait-il où une valeur de paramètre commence et se termine quand il reçoit une requête HTTP en utilisant multipart/form-data ?

Utiliser la limite , similaire à & .

Par exemple:

 --XXX Content-Disposition: form-data; name="name" John --XXX Content-Disposition: form-data; name="age" 12 --XXX-- 

Dans ce cas, la valeur limite est XXX . Vous le spécifiez dans l’en Content-Type tête Content-Type afin que le serveur sache comment diviser les données qu’il reçoit.

Donc, vous devez:

  • Utilisez une valeur qui n’apparaîtra pas dans les données HTTP envoyées au serveur.

  • Soyez cohérent et utilisez la même valeur partout dans le message de requête.

La réponse exacte à la question est: oui, vous pouvez utiliser une valeur arbitraire pour le paramètre de boundary , car il ne dépasse pas 70 octets de longueur et ne comprend que des US-ASCII (imprimables) de 7 bits .

Si vous utilisez l’un des types de contenu multipart/* , vous devez en fait spécifier le paramètre de boundary dans l’en Content-Type tête Content-Type , sinon le serveur (dans le cas d’une requête HTTP) ne pourra pas parsingr le Content-Type .

Vous souhaitez probablement également définir le paramètre charset sur UTF-8 dans votre en Content-Type tête Content-Type , sauf si vous êtes absolument certain que seuls US-ASCII caractères US-ASCII seront utilisés dans les données de charge.

Quelques extraits pertinents de la RFC2046 :

  • 4.1.2. Paramètre Charset:

    Contrairement à d’autres valeurs de paramètre, les valeurs du paramètre charset ne sont PAS sensibles à la casse. Le jeu de caractères par défaut, qui doit être supposé en l’absence d’un paramètre charset, est US-ASCII.

  • 5.1. Type de support multipart

    Comme indiqué dans la définition du champ Content-Transfer-Encoding [RFC 2045], aucun codage autre que “7bit”, “8bit” ou “binary” n’est autorisé pour les entités de type “multipart”. Les délimiteurs de limite et les champs d’en-tête “multipart” sont toujours représentés par US-ASCII à 7 bits (bien que les champs d’en-tête puissent coder des en-têtes non-US-ASCII conformément à RFC 2047) et que les données partie par partie, avec des champs Content-Transfer-Encoding pour chaque partie du corps appropriée.

    Le champ Content-Type pour les entités multipart nécessite un paramètre, “boundary”. La ligne de délimitation des limites est alors définie comme une ligne entièrement composée de deux traits d’union (“-“, valeur décimale 45) suivie de la valeur du paramètre limite du champ d’en-tête Content-Type, des espaces blancs optionnels et d’un CRLF final.

    Les délimiteurs de limites ne doivent pas apparaître dans le matériau encapsulé et ne doivent pas dépasser 70 caractères, sans compter les deux tirets principaux.

    La ligne de délimiteur de limite qui suit la dernière partie du corps est un délimiteur distinct qui indique qu’aucune autre partie du corps ne suivra. Une telle ligne de délimiteur est identique aux lignes de délimiteur précédentes, avec l’ajout de deux tirets supplémentaires après la valeur du paramètre de limite.

Voici un exemple utilisant une limite arbitraire:

 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 contient des limites pour séparer les paires nom / valeur. La limite agit comme un marqueur de chaque bloc de paires nom / valeur passé lorsqu’un formulaire est soumis. La limite est automatiquement ajoutée à un type de contenu d’un en-tête de demande.

La forme avec l’ atsortingbut enctype = “multipart / form-data” aura un en-tête de requête Content-Type: multipart / form-data; boundary — WebKit193844043-h (vaou généré par navigateur ).

La charge utile transmise ressemble à ceci:

 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-- 

Du côté des services Web, il est utilisé dans le formulaire @Consumes (“multipart / form-data”).

Attention, lorsque vous testez votre service Web à l’aide de chrome postman, vous devez cocher l’option Données de formulaire (bouton radio) et le menu Fichier du menu déroulant pour envoyer la pièce jointe. La fourniture explicite de type de contenu comme multipart / données de formulaire génère une erreur. Parce que les limites sont manquantes car elles écrasent la requête curl de post man sur le serveur avec content-type en ajoutant la limite qui fonctionne correctement.

Voir RFC1341 sec7.2 Le type de contenu multipart