hi,For a while I've noticed spurious CRLF at the end of body parts inside multipart MIME messages. I believe I have tracked this down to a couple of bugs in the gwlib/mime.c module, which is used heavily by Mbuni MMS Gateway.
Attached patch fixes these. Broadly, the code was too complicated for what should have been a simpler task (thanks partly to your truly!). I've tried to simplify the code to be true to RFC 2046 Sec. 5. Tests confirm that it is doing the right thing now.
In addition, the test case for multipart mime is actually mal-formed itself :(, lacking CRLF after each header, and at certain boundaries. A cleaner one is attached.
P.
mime.diff
Description: Binary data
Content-Type: multipart/related; start=<AAA>; boundary=my_boundary X-Some-Header: Some-Value MIME-Version: 1.0 --my_boundary Content-Type: text/plain this is the text in this entity --my_boundary Content-Type: multipart/mixed; boundary=mms_boundary MIME-Version: 1.0 --mms_boundary Content-Type: text/plain this is the mms message text --mms_boundary Content-Type: application/xml <?xml version="1.0"?> <!DOCTYPE pap PUBLIC "-//WAPFORUM//DTD PAP 2.0//EN" "http://www.wapforum.org/DTD/pap_2.0.dtd";> <pap> <push-message push-id="4879683648"> <address address-value="[EMAIL PROTECTED]"/> <address address-value="[EMAIL PROTECTED]"/> <address address-value="[EMAIL PROTECTED]"/> </push-message> </pap> --mms_boundary-- --my_boundary--
