Qu'est-ce que le paramètre de limite dans un HTTP multi-partie (POST) Demande?

Question

Je suis en train de développer un gadget qui automatise le processus de vérification d'une page web pour l'évolution de mon quota de transfert. Je suis presque à elle, mais il y a une dernière étape que j'ai besoin d'obtenir ce travail: l'Envoi d'un HttpRequest avec le bon POST de données à une page php. À l'aide d'un plugin 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" qui semble être aléatoire, et la 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 émuler correctement le POSTDATA avec le mystère de la "frontière" paramètre de retour.

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

Answer 1

Pour citer le RFC 1341, la section 7.2.1, ce que je considère être pertinents bits sur l' boundary paramètre de l' Content-Type - tête (MIME):

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

Le champ Content-Type pour multipart entités nécessite un paramètre, "frontière", qui est utilisé pour spécifier l'encapsulation de la frontière. L'encapsulation limite est définie comme une ligne entièrement composé de deux traits d'union ("-", code décimal 45), suivie par le paramètre limite de la valeur du Contenu Type de champ d'en-tête.

et puis précise:

Ainsi, un type de Contenu de type multipart en-tête de Type de champ pourrait ressembler à ceci:

 Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08jU534c0p

Cela indique que l'entité se compose de plusieurs parties, chacune avec 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

Choses à Noter:

1. L'encapsulation limite doit se produire au début d'une ligne, c'est à dire, à la suite d'un CRLF (Retour Chariot-saut de Ligne)
2. La limite doit être suivie immédiatement par une autre CRLF et les champs d'en-tête pour la prochaine partie, ou par deux CRLFs, auquel cas il n'existe pas de champs d'en-tête pour la prochaine partie (et il est donc supposé être de Content-Type text/plain).
3. L'Encapsulation des frontières ne doivent pas apparaître dans les dispositifs d'encapsulation, et doit être pas plus de 70 caractères, sans compter les deux principaux traits d'union.

Dernier mais non le moindre:

L'encapsulation de la frontière à la suite de la dernière partie de son corps est un éminent délimiteur qui indique que pas d'autres parties du corps suivra. Une telle séparation est identique à la précédente, les 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 dans l'avenir, comme je l'ai eu à errer pendant un certain temps avant d'obtenir l'image complète (veuillez vous assurer de lire la nécessaire les documents Rfc pour obtenir la compréhension la plus profonde).

Answer 2

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

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

Answer 3

La précision pour multipart/form-data est dans la RFC 2388. Limite est définie dans la Section 4.1.