What is the boundary parameter in an HTTP multi-part (POST) Request?

I am trying to develop a sidebar gadget that automates the process of checking a web page for the evolution of my transfer quota. I am almost at it but there is one last step I need to get it working: Sending an HttpRequest with the correct POST data to a php page. Using a firefox plugin, here is what the "Content-Type" of the header looks like:

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

with the parameter "boundary" seeming to be random, and the POSTDATA is this:

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

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

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

I do not understand how to correctly emulate the POSTDATA with the mystery "boundary" parameter coming back.

Would someone know how I can solve this?

To quote from the RFC 1341, section 7.2.1, what I consider to be the relevant bits on the boundary parameter of the Content-Type header (for MIME):

> All subtypes of "multipart" share a common syntax ...

>The Content-Type field for multipart entities requires one parameter, "boundary", which is used to specify the encapsulation boundary. The encapsulation boundary is defined as a line consisting entirely of two hyphen characters ("-", decimal code 45) followed by the boundary parameter value from the Content-Type header field.

and then clarifies:

>Thus, a typical multipart Content-Type header field might look like this:

 Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08jU534c0p

>This indicates that the entity consists of several parts, each itself with a structure that is syntactically identical to an RFC 822 message, except that the header area might be completely empty, and that the parts are each preceded by the line --gc0p4Jq0M2Yt08jU534c0p

Things to Note:

1. The encapsulation boundary must occur at the beginning of a line, i.e., following a CRLF (Carriage Return-Line Feed)
2. The boundary must be followed immediately either by another CRLF and the header fields for the next part, or by two CRLFs, in which case there are no header fields for the next part (and it is therefore assumed to be of Content-Type text/plain).
3. Encapsulation boundaries must not appear within the encapsulations, and must be no longer than 70 characters, not counting the two leading hyphens.

Last but not least:

>The encapsulation boundary following the last body part is a distinguished delimiter that indicates that no further body parts will follow. Such a delimiter is identical to the previous delimiters, with the addition of two more hyphens at the end of the line:

 --gc0p4Jq0M2Yt08jU534c0p-- 

I hope this helps someone else in the future, as I had to roam for a while before getting the full picture (please ensure to read the necessary RFCs to get the deepest understanding).

The boundary parameter is set to a number of hyphens plus a random string at the end, but you can set it to anything at all. The problem is, if the boundary string shows up in the request data, it will be treated as a boundary.

For some tips, and an example function for sending multipart/form-data see my answer to this question. It wouldn't be too difficult to modify that function to use a loop for each part you would like to send.

The actual specification for multipart/form-data is in RFC 7578. Boundary is defined in Section 4.1.