Quel est le paramètre limite dans une requête HTTP en plusieurs parties (POST) demande?

Question

Je suis en train de développer un gadget de la barre latérale qui permet d'automatiser le processus de vérification d'une page web pour l'évolution de mon quota de transfert. Je suis presque, mais il y a une dernière étape que je dois le faire fonctionner: Envoi d'un HttpRequest avec les données POST correctes à une page php. L'utilisation d'un plug-in Firefox, voici ce que le « Content-Type » de l'en-tête ressemble à:

Content-Type=multipart/form-data; boundary=---------------------------99614912995

avec le paramètre « limite » Semblant être aléatoire, et le POSTDATA est ceci:

POSTDATA =-----------------------------99614912995
Content-Disposition: form-data; name="SOMENAME"

Formulaire de Quota
-----------------------------99614912995
Content-Disposition: form-data; name="OTHERNAME"

SOMEDATA
-----------------------------99614912995--

Je ne comprends pas comment imiter correctement le POSTDATA avec le mystère paramètre « limite » à revenir.

Quelqu'un sait comment je peux résoudre ce problème?

Answer 1

Le paramètre limite est fixé à un certain nombre de traits d'union plus une chaîne aléatoire à la fin, mais vous pouvez le mettre à quoi que ce soit. Le problème est, si la chaîne limite apparaît dans les données de demande, elle sera traitée comme limite.

Pour quelques conseils, et une fonction d'exemple pour l'envoi multipart / form-data voir ma réponse à cette question. Il ne serait pas trop difficile de modifier cette fonction à utiliser une boucle pour chaque partie que vous souhaitez envoyer.

Answer 2

Pour citer le RFC 1341, section 7.2.1, ce que je considérer comme les bits correspondants sur le paramètre boundary de l'en-tête Content-Type (pour MIME):

  

Tous les sous-types de "multipart" partager une syntaxe commune ...

     

Le champ Content-Type pour les entités multipart nécessite un paramètre, « limite », qui est utilisée pour spécifier la limite d'encapsulation. La limite d'encapsulation est défini comme une ligne composée uniquement de deux traits d'union ( « - », le code décimal 45). Suivi de la valeur du paramètre de limite du champ d'en-tête Content-Type

et précise:

  

Ainsi, un champ d'en-tête typique multipart Content-Type pourrait ressembler à ceci:

 Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08jU534c0p

  

Ceci indique que l'entité se compose de plusieurs parties, chacune ayant lui-même une structure qui est syntaxiquement identique à un message RFC 822, sauf que la zone d'en-tête peut être complètement vide et que les parties sont chacune précédées par la ligne        --gc0p4Jq0M2Yt08jU534c0p

Les choses à noter:

1. La limite d'encapsulation doit avoir lieu au début d'une ligne, à savoir, après un CRLF (Retour chariot en ligne)
2. La frontière doit être suivi immédiatement, soit par un autre CRLF et les champs d'en-tête pour la partie suivante, ou par deux CRLFs, auquel cas il n'y a pas des champs d'en-tête pour la partie suivante (et il est donc supposé être de Content- Type text / plain).
3. limites Encapsulation ne doivent pas apparaître dans les encapsulations, et ne doivent pas être plus de 70 caractères, sans compter les deux traits d'union de premier plan.

Last but not least:

  

La limite d'encapsulation suivant la dernière partie du corps est un délimiteur unique qui indique qu'il n'y a pas d'autres parties du corps vont suivre. Un tel delimiter est identique aux précédents délimiteurs, avec l'ajout de deux traits d'union à la fin de la ligne:

 --gc0p4Jq0M2Yt08jU534c0p-- 

J'espère que cela aide quelqu'un d'autre à l'avenir, comme je devais errer pendant un certain temps avant d'obtenir l'image complète (s'il vous plaît assurez-vous de lire les RFCs nécessaires pour obtenir la plus profonde compréhension).

Answer 3

La spécification réelle pour multipart / form-data est en RFC 7578 . Limite est définie dans Section 4.1 .