[Python-bugs-list] [ python-Bugs-699600 ] MIMEText's c'tor adds unwanted trailing newline to text

[SourceForge.net]

Bugs item #699600, was opened at 2003-03-07 15:08
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699600&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Trent Mick (tmick)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: MIMEText's c'tor adds unwanted trailing newline to text

Initial Comment:
I have a web form that includes a "file" type <input>. 
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

----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-03-17 13:50

Message:
Logged In: YES 
user_id=12800

We decided to remove the \n since the mimelib crowd could
find no instances of broken code.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-03-10 12:22

Message:
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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699600&group_id=5470