Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 0.14.0

Bug #466 'MAIL_MIMEPART_CRLF' is defined as only line break. It must be '\r\n'
Submitted: 2003-12-19 22:23 UTC
From: ddykshoorn at speedlinesolutions dot com Assigned: arnaud
Status: Closed Package: SOAP
PHP Version: 4.3.4 OS: Win XP Pro
Roadmaps: (Not assigned)    
Subscription  
Comments Add Comment Add patch


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 33 - 11 = ?

 
 [2003-12-19 22:23 UTC] ddykshoorn at speedlinesolutions dot com
Description: ------------ I am using Base.php v1.40 and ran into a bug with the MAIL_MIMEPART_CRLF define('MAIL_MIMEPART_CRLF',"\n"); should be: define('MAIL_MIMEPART_CRLF',"\r\n"); 3rd party clients should be able to parse the Mime message but require end lines to be Char(13)Char(10) or \r\n. In base.php you define it as simply \n. In mimePart.php it is defined correctly as \r\n (in the Mail_mimePart function)however it seems to be a local definition so the definition in base.php definition takes presidence. mime encoded attachments do not have char(13)char(10) (or in php \r\n) they only have \n as line breaks. Mime Encoding must have \r\n in order to properly work with certain 3rd party SOAP clients. (like Delphi). ps. Keep up the good work. Reproduce code: --------------- Reproduce by creating a mime encoded attachment. Expected result: ---------------- All line breaks in Mime should have \r\n (Carriage Return, LineFeed). Actual result: -------------- Look at the line breaks at the end of the headers of what gets returned. you will only see a \n (or LineFeed).

Comments

 [2004-01-17 14:18 UTC] arnaud
You're right. That is what the mime specs say. Fixed in CVS, will be part of the upcoming release.