Invalid MIME boundary

Invalid MIME boundary SearchSearch
Author Message
Khwezi Mngoma
New member
Username: Nexus

Post Number: 5
Registered: 11-2003
Posted on Monday, January 05, 2004 - 06:46 am:   

Hello,

I was wondering if you could help me with this one, it is puzzeling me in the most intense of all ways. I have composed an MMS message and got myself a 4003 [Invalid MIME boundary] soap response. I dont know what it wants from me exactly, I am not even sure I know how to solve this problem. COuld it be that there is a way of encoding boundaries in some specific formar relying on some standard. If there is, please tell me. Below is the submission and resonse (i have truncated the message for space saving purposes:

Request:
***************************
Content-Type: multipart/related; boundary='Part_0_156B1078E5404.A39A9A92220B6'
Content-Length: n
SOAPAction:

--Part_0_156B1078E5404.A39A9A92220B6
Content-Type: text/xml; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-ID: <MIG_MMS_13F969154>

<?xml version="1.0"?><env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"><env:Header><mm7:TransactionID xmlns:mm7="http://www.3gpp.org/MMS/Rel5/MM7/v0.09">2004/01/05 08:24:17 AM3913B</mm7:TransactionID></env:Header><env:Body><SubmitReq xmlns="http://www.3gpp.org/MMS/Rel5/MM7/v0.09"><MM7Version>5.3.0</MM7Version><SenderIdentification><VASPID>MIG</VASPID><Sende rAddress>27876543211</SenderAddress></SenderIdentification><Recipients><To><Numb er>27722484102</Number></To></Recipients><MessageClass>Informational</MessageCla ss><Priority>Normal</Priority><Expiry>2004/01/06 06:24:17 AM</Expiry><Subject>MIG Test MMS Message</Subject><Content href="cid:MIG_MMS_13F969154" /><DeliveryReport>True</DeliveryReport><ReadReply>False</ReadReply></SubmitReq>< /env:Body></env:Envelope>

--Part_0_156B1078E5404.A39A9A92220B6
Content-Type: image/jpeg; name=peachro.jpg
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=peachro.jpg

/9j/4AAQSkZJRgABAQEASABIAAD/7AARRHVja3kAAQAEAAAAIAAA/9sAQwAIBgYHBgUIBwcHCQkICgwU DQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwY DQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AA EQgAPAA8AwERAAIRAQMRAf/EABoAAA
......snip snip

--Part_0_156B1078E5404.A39A9A92220B6
Content-Type: Content-Type: text/plain; charset='us-ascii'

This is a test MMS text message.

--Part_0_156B1078E5404.A39A9A92220B6--

***********************
Request Response:
***********************
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header>
<mm7:TransactionID xmlns:mm7="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0" env:mustUnderstand="1">
unknown
</mm7:TransactionID>
</env:Header>
<env:Body>
<mm7:RSErrorRsp xmlns:mm7="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0">
<MM7Version>5.3.0</MM7Version>
<Status>
<StatusCode>4003</StatusCode>
<StatusText>Unsupported Operation</StatusText>
<Details>Invalid MIME boundary</Details>
</Status>
</mm7:RSErrorRsp>
</env:Body>
</env:Envelope>


Please help me, this is the only thing between me and success. :-(
Khwezi Mngoma
New member
Username: Nexus

Post Number: 7
Registered: 11-2003
Posted on Monday, January 05, 2004 - 12:12 pm:   

I have redesigned my transmiter and found myself in the same hot knot, I have studied the RFC1521 and RFC0822 in details, and I am at a loss for words s to why I keep on getting the "Invalid MIME Boundary" error message from NowSMS. Please help me out - I am begging. Maybe you will have a fresher outlook. I have extracted the HTTP-POST request, please take a look (I have truncated the message payload):

User-Agent: MIG MMS Titan II
Content-Type: multipart/mixed; boundary="Part.D6C9D102ECA0_96A0A87515830"; type=text/xml; start="<MIG_MMS_16DF63EFA>"
SOAPAction: ""
Authorization: Basic TUlHOjEyMzQ1
Content-Length: 8711
Expect: 100-continue
Connection: Close
Host: localhost:8082

--Part.D6C9D102ECA0_96A0A87515830
Content-Type: text/xml; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-ID: <MIG_MMS_16DF63EFA>

<?xml version="1.0"?><env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"><env:Header><mm7:TransactionID xmlns:mm7="http://www.3gpp.org/MMS/Rel5/MM7/v0.09">2004/01/05 01:56:02 PM1C0CB</mm7:TransactionID></env:Header><env:Body><SubmitReq xmlns="http://www.3gpp.org/MMS/Rel5/MM7/v0.09"><MM7Version>5.3.0</MM7Version><SenderIdentification><VASPID>MIG</VASPID><Sende rAddress>27876543211</SenderAddress></SenderIdentification><Recipients><To><Numb er>27722484102</Number></To></Recipients><MessageClass>Informational</MessageCla ss><Priority>Normal</Priority><Expiry>2004/01/08 11:56:02 AM</Expiry><Subject>MIG Test MMS Message</Subject><Content href="cid:MIG_MMS_SOAP_AC309F36" /><DeliveryReport>True</DeliveryReport><ReadReply>False</ReadReply></SubmitReq>< /env:Body></env:Envelope>

--Part.D6C9D102ECA0_96A0A87515830
Content-Type: multipart/mixed; boundary="StoryPart.F4F0A6D95EC1_124E9AE54241FC"
Content-ID: <MIG_MMS_SOAP_AC309F36>


--StoryPart.F4F0A6D95EC1_124E9AE54241FC
Content-Type: image/jpeg
Content-ID: <peachro.jpg>
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAQEASABIAAD/7AARRHVja3kAAQAEAAAAIAAA/9sAQwAIBgYHBgUIBwcHCQkICgwU DQwLC
.....snip snip

--StoryPart.F4F0A6D95EC1_124E9AE54241FC
Content-Type: Content-Type: text/plain; charset=us-ascii

This is a test MMS text message.

--StoryPart.F4F0A6D95EC1_124E9AE54241FC
Content-Type: audio/amr
Content-Transfer-Encoding: base64
Content-ID: <yahoo.amr>

IyFBTVIKPEaUeKRO0ERs62+rJhNHIUAAcst7kdc0AAGl2b8MFAA8cvNrip5dJx5TxPf8sGnPA71qjpfb p4nTg2VnagOkIDy
...snip snip

--StoryPart.F4F0A6D95EC1_124E9AE54241FC--
--Part.D6C9D102ECA0_96A0A87515830--
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 1509
Registered: 10-2002
Posted on Monday, January 05, 2004 - 09:30 pm:   

The second MM7 example is better than the first.

The primary problem with the first is that the MMS content should be in the second part of the multipart, and it is essentially an embedded multipart (like in the second example, where the "StoryPart" boundary is added).

I'm trying to figure out why the example in the second message would generate an error, but I don't see anything obvious.

The "Invalid MIME boundary" error occurs when we cannot find an initial boundary marker that matches the one specified in the "Content-type:" header of the HTTP POST.

The only thing that I could think of causing a problem is if there was a NULL character somewhere between the HTTP header and that first boundary. (There is a hex dump in the MMSCDEBUG.LOG of the received data ... could this be the case?)
Khwezi Mngoma
New member
Username: Nexus

Post Number: 8
Registered: 11-2003
Posted on Tuesday, January 06, 2004 - 09:23 am:   

Thanks for the response Bryce, I think you work very hard.

As far as the log file you refered to above, I did not find it (even after doing a system search). That left me with no obtion but to go through my Composer/Transmitter code and find anything that could help. I found nothing more than two line breaks after the Main HTTP header (before the first boundary appears).

I got rid of the one line break (I put it there thinking that it would help make things look neater). All of that did not make any kind of difference. I am not sure what I am supposed to do. When I read through RFC1521 I got the idea that the boundary can be anything as long as it is no longer than 70 character, when it is used it must be preceeded by a --, when you end the message it must have another -- at the end and the last bit was that it must be unique within the message. I am not sure if NowMMS wants it in some format...

I am so close yet so far, I am not sure I can help myself beyond this hurdle. I dont know where to from now, maybe I am missing something, i dont know...
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 1524
Registered: 10-2002
Posted on Tuesday, January 06, 2004 - 07:52 pm:   

Khwezi,

Sorry, I should have explained how to enable the debug log.

Manually edit MMSC.INI, and under the [MMSC] section header, add Debug=Yes. Then restart the Now MMSC service.

Repeat your MM7 post attempt.

The data should be logged into MMSCDEBUG.LOG. Post that log as an attachment, and I'll be able to tell you exactly what is going wrong based upon that information.

-bn
Khwezi Mngoma
New member
Username: Nexus

Post Number: 9
Registered: 11-2003
Posted on Wednesday, January 07, 2004 - 08:32 am:   

Hi Bryce,

I have done as you asked, and I am now even more confused. I took a look in the debug file and found a lot of NULLs and no body content after the Authorization section. I have decided to attach the file because it is a bit too long to paste in here (it would be impolite also). If this null between the header and the first boundary is supposed to exist for my problem to persist, then it is in a bundence. All I know is that I did not put all those nulls there. And there is deffinetely no nulls in my composition. The message is built through STRING appendiges.

Please see the attached file.
application/octet-streamMMSCDEBUG.TXT File
MMSCDEBUG.LOG (25.0 k)
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 1537
Registered: 10-2002
Posted on Wednesday, January 07, 2004 - 06:35 pm:   

Hi Khwezi,

I can't see where the nulls would be coming from if they were not actually being posted by the application.

That log includes a dump of the data that was received over the connection, before any processing is performed against the data. It is possible that more data was received than is displayed in the log, because we do truncate the data based upon the "content-length" header, but other than that, the dump should contain exactly the data that was received.

So, while this example shows 1316 nulls, which matches the Content-Length, it is possible that more data was sent, but that NowSMS truncated it because the Content-Length field was 1316.

Technically, I believe that according to the MIME spec, you could have NULLs between the end of the HTTP header and the first boundary, but NowSMS definitely does not like them. (In fact, the v5.0 release of NowSMS does not like NULLs anywhere in an MM7 request, although the patch that you can download does allow NULLs within individual content pieces if you did not encode them with base64 or quoted-printable.)

Anyway, I think something is going wrong with your string operation before you submit the data. I can't see how NowSMS would see the NULLs if they were not there.

-bn
Khwezi Mngoma
New member
Username: Nexus

Post Number: 10
Registered: 11-2003
Posted on Thursday, January 08, 2004 - 11:22 am:   

Thanks Bryce,

You have gone beyond the fringes, further than any technical support person has ever. For this I am eternally grateful to you.

I went through my code, all 3000+ lines of it and found that I had left out the message payload and only sent the main header. This is why you can't see the rest of the message in the MMSDEBUG.TXT file.

I am sorry for my clumsyness, in the midst of all my troubles, I had neglected to include just one line in my transmitter that writes the message payload onto the server after authentication :-( sorry.

I have since successfully sent a number of MMS messages. I very extrememly good. Thanks you.