| NowSMS HTTP Interface |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - MMS & Advanced Issues ⬆ Archive through June 06, 2005 ⬆ |
◄ ► |
| Author | Message | |||||
| Anonymous |
Hi, I have the NowSMS configured to send MMS messages, and I can send MMS messages using the web interface provided with NowSMS. However, when I try to POST the same contents with my code I get the MMS notification and the text, however the gif does not show up. I get an error on my phone that says "unsupported content image/gif". I know that my phone supports gif because it works with the NowSMS web interface. I looked at the log files and there are about 8 bytes that are different between the log file that get's generated when sending the same MMS using the web interface and my code for POST. I am attaching the log files. Any help would be appreciated. Thanks Ashwin
| |||||
| Anonymous |
Hi, As a followup, I see the following differences in the MMSDebug log files genereated when I post using NowSMS Web interface and when I post using my code: ---- NowSMS Web Interface debug file has the following bytes after the subject field which the log file generated by my post does not have: 8A 80 8F 81 86 81 90 81 Can someone help me understand why this is. Thanks Ashwin | |||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 3806 Registered: 10-2002 |
Hi Ashwin, Are the GIF files in the two logs (bunny.gif) the exact same file? I notice that there is a 5 byte difference in the size between the two attempts. Your HTTP post result ends up with a 4 byte larger GIF file. I can see that there is an extra CRLF at the end of the GIF, which would account for 2 of those bytes. (And we should look at our decoding logic to check on this.) But I'm not sure about the other 2 bytes. Is it possible for you to capture the raw POST from your application? (Maybe with Ethereal?) Wait ... I've found the other 2 extra bytes. There is a CRLF at the start of the GIF as well as at the end. Check the way that your multipart form is encoded, as I think there are extra CRLF's that are causing problems. It should look like this ... with one blank line between the MIME header and the first byte of the GIF. I'll insert the <CRLF> where you should have a CRLF line break: ----boundary-border----<CRLF> Content-Disposition: form-data; name="MMSFile"; filename="bunny.gif"<CRLF> Content-type: image/gif<CRLF> <CRLF> Image data goes here<CRLF-optional> ----boundary-border----<CRLF> Here is what I think is happening with your post: ----boundary-border----<CRLF> Content-Disposition: form-data; name="MMSFile"; filename="bunny.gif"<CRLF> Content-type: image/gif<CRLF> <CRLF><CRLF> Image data goes here<CRLF><CRLF> ----boundary-border----<CRLF> The extra <CRLF> before and after the image are being interpreted as part of the image data, which is causing the image to be corrupted. -bn | |||||
| Anonymous |
Hi Bryce, Thank you for your help. That worked. Thanks Ashwin | |||||
| Anonymous |
Hi Bryce, Your suggestion worked, but I am still confused as to why the following byte sequence 8A 80 8F 81 86 81 90 81 is part of the MMS file generated by the NowSMS Web interface and is not present when the MMS file is created when I post using my code. The byte sequence is present after the subject field. Any explanation for this will be appreciated. Thanks Ashwin | |||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 3888 Registered: 10-2002 |
Hi Ashwin, Apologies for the delay in follow-up. Basically, the NowSMS web interface sets some default values for some MMS message attributes. It has to do with the checkboxes on the form for attributes "Message Class", "Priority", "Delivery Report", and "Read Reply". Even though the default values on our web form are set for the default values in an MMS message if the setting is not present ... our logic in the server is that if the post contains a value for a setting, we encode it in the MMS message. 8A 80 Message-Class = Personal 8F 81 Priority = Normal 86 81 Delivery-Report = No 90 81 Read-Report = No If your post included HTTP variable settings for "MMSMessageClass", "MMSPriority", "MMSDeliveryReport", and/or "MMSReadReport", then the server would set these values for your direct post submission as well. -bn | |||||
Log files genetrated with my code.
