Can't use requests for mime-encoded data as per RFC 1341 sec. 7.2.1

I've been sweating on this for the past 48 hours, I just can't seem to find a way (not even in the docs) to use requests to send a custom mime entity digest payload to a server over http.

The use case am dealing with requires the composition and posting (via HTTP) of a MIME encoded SOAP MMS Message. This requires the use of the "multipart/*" family of Content Types and the ability to have the "boundary" and "start" parameters of Content-Type also included (see RFC 1341 Sec. 7.2.1). Am sure even the common "multipart/*" kinds supported by HTTP POST ought to have these values set, a closer probing of the payload of requests.post (even with files!) shows that these values aren't used in the body (or am I wrong?)

Please, am suspecting there must be a not-far-fetched means to achieve this in requests. Please advise. 

NOTE: This kind of ability would allow the composition of such a message (see below) as the payload sent using HTTP POST:

```
POST /mms-rs/mm7 HTTP/1.1
Host: mms.omms.com
Content-Type: multipart/related; boundary=”NextPart_000_0028_01C19839.84698430"; type=text/xml;
start=”</tnn-200102/mm7-submit>”
Content-Length: nnnn
SOAPAction: “”
-- NextPart_000_0028_01C19839.84698430
Content-Type:text/xml; charset=”utf-8”
Content-ID: </tnn-200102/mm7-submit>
<?xml version=’1.0’ ?>
<env:Envelope xmlns:env="http:// schemas.xmlsoap.org/soap /soap-envelope">
<env:Header>
<mm7:TransactionID xmlns:mm7=”http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-env:mustUnderstand=”1”>
vas00001-sub
</mm7:TransactionID>
</env:Header>
<env:Body>
<mm7:SubmitReq xmlns:mm7="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0<MM7Version>5.3.0</MM7Version>
<SenderIdentification>
<VASPID>TNN</VASPID>
<VASID>News</VASID>
</SenderIdentification>
<Recipients>
<To>
<Number>7255441234</Number>
<RFC2822Address displayOnly=”True”>7255442222@OMMS.com</RFC2822Address>
</To>
<Cc>
<Number>7255443333</Number>
</Cc>
<Bcc>
<RFC2822Address>7255444444@OMMS.com</RFC2822Address>
</Bcc>
</Recipients>
<ServiceCode>gold-sp33-im42</ServiceCode>
<LinkedID>mms00016666</LinkedID>
<MessageClass>Informational</MessageClass>
<TimeStamp>2002-01-02T09:30:47-05:00</Date>
<EarliestDeliveryTime>2002-01-02T09:30:47-05:00</EarliestDeliveryTime>
<ExpiryDate>P90D</ExpiryDate>
<DeliveryReport>True</DeliveryReport>
<Priority>Normal</Priority>
<ChargedParty>Sender</ChargedParty>
<DistributionIndicator>True</ DistributionIndicator>
<Subject>News for today</Subject>
<Content href=”cid:SaturnPics-01020930@news.tnn.com”; allowAdaptations=”True”/>
</mm7:SubmitReq>
</env:Body>
</env:Envelope>
-- NextPart_000_0028_01C19839.84698430
Content-Type: multipart/mixed; boundary=”StoryParts 74526 8432 2002-77645”
Content-ID:< SaturnPics-01020930@news.tnn.com>

-- StoryParts 74526 8432 2002-77645
Content-Type: text/plain; charset="us-ascii"
Science news, new Saturn pictures...
-- StoryParts 74526 8432 2002-77645
Content-Type: image/gif;
Content-ID:<saturn.gif>
R0lGODdhZAAwAOMAAAAAAIGJjGltcDE0OOfWo6Ochbi1n1pmcbGojpKbnP/lpW54fBMTE1RYXEFO
-- StoryParts 74526 8432 2002-77645 --
--_NextPart_000_0028_01C19839.84698430--
```

Note the use the "boundary" and "start" parameters and fields to demarcate where XML starts, where binary data is, where text is, etc. Please help.


Requests doesn't stop you from doing this.


Just pass everything you want as a bytestring to the `data` parameter.


Am mostly concerned about the very first headers:

```
POST /mms-rs/mm7 HTTP/1.1
Host: mms.omms.com
Content-Type: multipart/related; boundary=”NextPart_000_0028_01C19839.84698430"; type=text/xml;
start=”</tnn-200102/mm7-submit>”
Content-Length: nnnn
SOAPAction: “”
```

Will those get used as the HTTP Headers instead? Because in this case the very first headers are important as they specify the entry into the rest of the SOAP Message Body. In this case (based on your theory), I would assume that the default Content-Type "multipart/*" for the HTTP POST would get replaced with the above? I'd already tried constructing this entire payload manually, but didn't seem to succeed, so I thought otherwise.


True, I was able to solve this very nicely by setting a custom "Content-Type" in the HTTP headers, and then putting all my other SOAP Mime stuff in the bytestring like you said. Thanks for this awesome lib :-)