Issue 699600: MIMEText's c'tor adds unwanted trailing newline to text (original) (raw)

Issue699600

➜

This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

This issue has been migrated to GitHub: https://github.com/python/cpython/issues/38125

classification

process

Created on 2003-03-07 20:08 by tmick, last changed 2022-04-10 16:07 by admin. This issue is now closed.

Messages (3)
msg15023 - (view)	Author: Trent Mick (tmick)	Date: 2003-03-07 20:08
I have a web form that includes a "file" type . This means that it expects the HTTP POST data to be of type multipart/form-data. I was using the 'email' package to build this Message essentially like this: message = MIMEMultipart(_subtype="form-data") # for each non-file input part = MIMEText(partValue) message.attach(part) # for each file input content = open(filename, 'rb).read() part = MIMEText(content) message.attach() this results in a message body (headers removed) like the following: --===============25164547096797829== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: form-data; name="logfile"; filename="D:\\trentm\\tmp\\seuss.txt" one fish two fish three fish blue fish --===============25164547096797829== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: form-data; name="name" pliers --===============25164547096797829==-- The problem is those extra newlines after "blue fish" and after "pliers". My uploaded file "D:\\trentm\\tmp\\seuss.txt" does not have a newline at the end. The result is that the file is changed (albeit slightly) on an HTTP upload. If I use IE6 or Mozilla 1.3 to file out this web form the multipart/form-data messages they generate do NOT include those extra newlines. The newlines were added by this code in the MIMEText's constructor: if text[-1] <> '\n': text += '\n' which has been around for a long time: http://cvs.sourceforge.net/cgi- bin/viewcvs.cgi/mimelib/mimelib/mimelib/Text.py.diff? r1=1.1&r2=1.2 No real reason was given for adding this code, and it seems hard to defend it because if I change the above to the following I do not get the extra newlines: message = MIMEMultipart(_subtype="form-data") # for each non-file input part = MIMEText(None) part.set_payload(partValue) message.attach(part) # for each file input content = open(filename, 'rb).read() part = MIMEText(None) part.set_payload(content) message.attach() I suppose it is possible that there is a backward compatibility issue in changing this behaviour. You would be a better judge of that impact, Barry. Perhaps you could kill two birds with one stone and deprecate MIMEText in favor of a newly named one that drops the already deprecated _encoding argument as well. Cheers, Trent
msg15024 - (view)	Author: Barry A. Warsaw (barry) *	Date: 2003-03-10 17:22
Logged In: YES user_id=12800 I believe this was added to make sure that when a MIMEText was a subpart, the missing newline wouldn't break the appending of the boundary text. But we've since fixed that breakage in another way, so I think the code in MIMEText is wrong. Eliminating it breaks a bunch of unit tests but they appear easily reparable. The b/w compat issues are tougher since there may indeed be code relying on this. I don't want to deprecate the whole MIMEText class. Maybe the least painful is to add an argument to decide whether to add the newline or not. I'll bring this up on mimelib-devel and see what the consensus is.
msg15025 - (view)	Author: Barry A. Warsaw (barry) *	Date: 2003-03-17 18:50
Logged In: YES user_id=12800 We decided to remove the \n since the mimelib crowd could find no instances of broken code.