Éric pointed out that given that the default was documented as None, someone
would reasonably pass that to get the default behavior. In fixing the code to
use None, I noticed that the change to _charset was being done after it had
already been passed to MIMENonMultipart. The change to the test verifies that
the order is now correct.
Previously it would just accept the unicode, which would wind up as unicode in
the transfer-encoded message object, which is just wrong.
Patch by Jeff Knupp.
In Python2, if a unicode string was assigned as the value of a header,
email would automatically CTE encode it using the UTF8 charset.
This capability was lost in the Python3 translation, and this patch
restores it.
Patch by Ali Ikinci, assisted by R. David Murray.
I also added a fix for the mailbox test that was depending (with a comment
that it was a bad idea to so depend) on non-ASCII causing message_from_string
to raise an error. It now uses support.patch to induce an error during
message serialization.
In Python2, if a unicode string was assigned as the value of a header,
email would automatically CTE encode it using the UTF8 charset.
This capability was lost in the Python3 translation, and this patch
restores it.
Patch by Ali Ikinci, assisted by R. David Murray.
I also added a fix for the mailbox test that was depending (with a comment
that it was a bad idea to so depend) on non-ASCII causing message_from_string
to raise an error. It now uses support.patch to induce an error during
message serialization.
Analogous to the decode_header fix, this fix makes Header.append and
make_header correctly handle the unknown-8bit charset introduced by email5.1,
when the input to them is binary strings. Previous to this fix the
make_header(decode_header(x)) == x invariant was broken in the face of the
unknown-8bit charset.
This new interface will also allow for future planned enhancements
in control over the parser/generator without requiring any additional
complexity in the parser/generator API.
Patch reviewed by Éric Araujo and Barry Warsaw.
Why I consider this a bug rather than an API change: the API change was
to Message, which didn't used to return Headers unless you added them
yourself. Now it does (for 8bit binary header input), so decode_header
needs to be able to handle them.
The fix is to charset.py, which was not doing the encoding to the
correct output character set when doing a body_encode for either
the shift-jis or euc-jp charsets. There's also a fix for handling
a bytes input in encoders.py.
Patch by Michael Henry, comment changes by me.
When a header was long enough to need to be split across lines, the
input charset name was used instead of the output charset name in
the encoded words. This make a difference only for the two charsets
above.
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r87136 | r.david.murray | 2010-12-08 17:53:00 -0500 (Wed, 08 Dec 2010) | 6 lines
Have script_helper._assert_python strip refcount strings from stderr.
This makes the output of the function and those that depend on it
independent of whether or not they are being run under a debug
build.
........
r87221 | r.david.murray | 2010-12-13 19:55:46 -0500 (Mon, 13 Dec 2010) | 4 lines
#10699: fix docstring for tzset: it does not take a parameter
Thanks to Garrett Cooper for the fix.
........
r87256 | r.david.murray | 2010-12-14 21:19:14 -0500 (Tue, 14 Dec 2010) | 2 lines
#10705: document what the values of debuglevel are and mean.
........
r87337 | r.david.murray | 2010-12-17 11:11:40 -0500 (Fri, 17 Dec 2010) | 2 lines
#10559: provide instructions for accessing sys.argv when first mentioned.
........
r87338 | r.david.murray | 2010-12-17 11:29:07 -0500 (Fri, 17 Dec 2010) | 2 lines
#10454: clarify the compileall docs and help messages.
[compileall.py changes not backported.]
........
r87571 | r.david.murray | 2010-12-29 14:06:48 -0500 (Wed, 29 Dec 2010) | 2 lines
Fix same typo in docs.
........
r87839 | r.david.murray | 2011-01-07 16:57:25 -0500 (Fri, 07 Jan 2011) | 9 lines
Fix formatting of values with embedded newlines when rfc2047 encoding
Before this patch if a value being encoded had an embedded newline,
the line following the newline would have no leading whitespace,
and the whitespace it did have was encoded into the word. Now
the existing whitespace gets turned into a blank, the way it does
in other header reformatting, and the _continuation_ws gets added
at the beginning of the encoded line.
........
r88164 | r.david.murray | 2011-01-24 14:34:58 -0500 (Mon, 24 Jan 2011) | 12 lines
#10960: fix 'stat' links, link to lstat from stat, general tidy of stat doc.
Original patch by Michal Nowikowski, with some additions and wording
fixes by me.
I changed the wording from 'Performs a stat system call' to 'Performs
the equivalent of a stat system call', since on Windows there are no
stat/lstat system calls involved. I also extended Michal's breakout
of the attributes into a list to the other paragraphs, and rearranged
the order of the paragraphs in the 'stat' docs to make it flow
better and put it in what I think is a more logical/useful order.
........
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r87873 | r.david.murray | 2011-01-08 21:35:24 -0500 (Sat, 08 Jan 2011) | 12 lines
#5871: protect against header injection attacks.
This makes Header.encode throw a HeaderParseError if it winds up
formatting a header such that a continuation line has no leading
whitespace and looks like a header. Since Header accepts values
containing newlines and preserves them (and this is by design), without
this fix any program that took user input (say, a subject in a web form)
and passed it to the email package as a header was vulnerable to header
injection attacks. (As far as we know this has never been exploited.)
Thanks to Jakub Wilk for reporting this vulnerability.
........
This makes Header.encode throw a HeaderParseError if it winds up
formatting a header such that a continuation line has no leading
whitespace and looks like a header. Since Header accepts values
containing newlines and preserves them (and this is by design), without
this fix any program that took user input (say, a subject in a web form)
and passed it to the email package as a header was vulnerable to header
injection attacks. (As far as we know this has never been exploited.)
Thanks to Jakub Wilk for reporting this vulnerability.
This applies only when generating strings from non-RFC compliant binary
input; it makes the existing recoding behavior more consistent (ie:
now no data is lost when recoding).
Before this patch if a value being encoded had an embedded newline,
the line following the newline would have no leading whitespace,
and the whitespace it did have was encoded into the word. Now
the existing whitespace gets turned into a blank, the way it does
in other header reformatting, and the _continuation_ws gets added
at the beginning of the encoded line.
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r87750 | r.david.murray | 2011-01-04 20:39:32 -0500 (Tue, 04 Jan 2011) | 5 lines
#10790: make append work when output codec is different from input codec
There's still a bug here (the encode call shouldn't use the 'errors'
paramter), but I'll fix that later.
........
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r87567 | r.david.murray | 2010-12-29 11:57:24 -0500 (Wed, 29 Dec 2010) | 2 lines
Fix a comment typo and update another comment to match Python3 reality
........
The RFC is bit hard to understand on this point, but the examples
clearly show that parameter values that are encoded according
to its charset/language rules don't have surrounding quotes, and
the ABNF does not allow for quotes. So when we produce such
encoded values, we no longer add quotes.
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r87415 | r.david.murray | 2010-12-21 13:07:59 -0500 (Tue, 21 Dec 2010) | 4 lines
Fix the change made for issue 1243654.
Surprisingly, it turns out there was no test that exercised this code path.
........
Such addresses are not RFC compliant except under the 'obsolete syntax'
rules, but before this fix the whitespace was dropped from the input,
concatenating the pieces. That breaks one of the principles of the
email package, that of preserving the input as much as possible.
It also denies the application program the opportunity to apply its
own heuristics to interpretation of such non-compliant addresses.
It is possible users of the email package were depending on the local
part always being a single token, so this fix will not be backported.
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r87217 | r.david.murray | 2010-12-13 18:51:19 -0500 (Mon, 13 Dec 2010) | 5 lines
#1078919: make add_header automatically do RFC2231 encoding when needed.
Also document the use of three-tuples if control of the charset
and language is desired.
........
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r87191 | r.david.murray | 2010-12-12 15:06:19 -0500 (Sun, 12 Dec 2010) | 6 lines
#243654: only create a new MIME boundary if we don't already have one.
The rearranged code should do exactly what the old code did, but
the new code avoids a potentially costly re computation in the case
where a boundary already exists.
........
The rearranged code should do exactly what the old code did, but
the new code avoids a potentially costly re computation in the case
where a boundary already exists.
The tests that were failing on (some) windows machines, where the
msg_XX.txt files used native \r\n lineseps are now also run on machines
that use \n natively, and conversely the \n tests are run on Windows.
The failing tests revealed one place where linesep needed to be added
to a flatten call in generator. There was also another that the tests
didn't catch, so I added a test for that case as well.
The work on this is not 100% complete, but everything is present to
allow real-world testing of the code. The only remaining major todo
item is to (hopefully!) enhance the handling of non-ASCII bytes in headers
converted to unicode by RFC2047 encoding them rather than replacing them with
'?'s.
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r85179 | r.david.murray | 2010-10-02 11:58:26 -0400 (Sat, 02 Oct 2010) | 6 lines
#1050268: make parseaddr 'quote' the contents of quoted strings in addresses.
Also made the doc string for email._parseaddr's 'quote' function more
accurate; I'd love to make the function match the old docstring instead,
but other code uses it according the existing semantics.
........
Also made the doc string for email._parseaddr's 'quote' function more
accurate; I'd love to make the function match the old docstring instead,
but other code uses it according the existing semantics.
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r85142 | r.david.murray | 2010-10-01 11:40:20 -0400 (Fri, 01 Oct 2010) | 5 lines
#10004: in Q encoded word ignore '=xx' when xx is not valid hex.
Bug report and fix by Thomas Guettler.
........
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r84310 | r.david.murray | 2010-08-24 20:45:55 -0400 (Tue, 24 Aug 2010) | 8 lines
#1194222: make parsedate always return RFC2822 four character years.
Two character years are now converted to four character years using
the Posix standard rule (<68 == 2000, >=68==1900). This makes the
parsed date RFC2822 compliant even if the input is not.
Patch and test by Jeffrey Finkelstein.
........
Two character years are now converted to four character years using
the Posix standard rule (<68 == 2000, >=68==1900). This makes the
parsed date RFC2822 compliant even if the input is not.
Patch and test by Jeffrey Finkelstein.
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r83690 | r.david.murray | 2010-08-03 18:14:10 -0400 (Tue, 03 Aug 2010) | 10 lines
#3196: if needed pad a short base64 encoded word before trying to decode.
The RFCs encourage following Postel's law: be liberal in what you accept.
So if someone forgot to pad the base64 encoded word payload to an
even four bytes, we add the padding before handing it to base64mime.decode.
Previously, missing padding resulted in a HeaderParseError.
Patch by Jason Williams.
........
The RFCs encourage following Postel's law: be liberal in what you accept.
So if someone forgot to pad the base64 encoded word payload to an
even four bytes, we add the padding before handing it to base64mime.decode.
Previously, missing padding resulted in a HeaderParseError.
Patch by Jason Williams.
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r82922 | r.david.murray | 2010-07-16 21:19:57 -0400 (Fri, 16 Jul 2010) | 4 lines
#1555570: correctly handle a \r\n that is split by the read buffer.
Patch and test by Tony Nelson.
........
svn+ssh://pythondev@svn.python.org/python/branches/py3k
................
r82011 | r.david.murray | 2010-06-15 22:19:40 -0400 (Tue, 15 Jun 2010) | 17 lines
Merged revisions 81675 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r81675 | r.david.murray | 2010-06-03 11:43:20 -0400 (Thu, 03 Jun 2010) | 10 lines
#5610: use \Z not $ so we don't eat extra chars when body part ends with \r\n.
If a body part ended with \r\n, feedparser, using '$' to terminate its
search for the newline, would match on the \r\n, and think that it needed
to strip two characters in order to account for the line end before the
boundary. That made it chop one too many characters off the end of
the body part. Using \Z makes the match correct.
Patch and test by Tony Nelson.
........
................
svn+ssh://pythondev@svn.python.org/python/trunk
........
r81675 | r.david.murray | 2010-06-03 11:43:20 -0400 (Thu, 03 Jun 2010) | 10 lines
#5610: use \Z not $ so we don't eat extra chars when body part ends with \r\n.
If a body part ended with \r\n, feedparser, using '$' to terminate its
search for the newline, would match on the \r\n, and think that it needed
to strip two characters in order to account for the line end before the
boundary. That made it chop one too many characters off the end of
the body part. Using \Z makes the match correct.
Patch and test by Tony Nelson.
........
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r81685 | r.david.murray | 2010-06-04 12:11:08 -0400 (Fri, 04 Jun 2010) | 4 lines
#4768: store base64 encoded email body parts as text, not binary.
Patch and tests by Forest Bond.
........
svn+ssh://pythondev@svn.python.org/python/branches/py3k
................
r81660 | r.david.murray | 2010-06-02 21:58:28 -0400 (Wed, 02 Jun 2010) | 25 lines
Fix Charset.body_encode to encode to output_charset before calling base64mime.
This means that what gets encoded in base64 is the encoded version of the
unicode payload. This bug was revealed by a forward port of the tests from
Issue 1368247, but the fix was completely different.
Note that the merge is only of the tests, the doc changes were inappropriate
since email5 expects unicode, not bytes. I'm also not convinced that
quopri works correctly in email5, but that's a different issue.
Merged revisions 81658 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r81658 | r.david.murray | 2010-06-02 18:03:15 -0400 (Wed, 02 Jun 2010) | 9 lines
#1368247: make set_charset/MIMEText automatically encode unicode _payload.
Fixes (mysterious, to the end user) UnicodeErrors when using utf-8 as
the charset and unicode as the _text argument. Also makes the way in
which unicode gets encoded to quoted printable for other charsets more
sane (it only worked by accident previously). The _payload now is encoded
to the charset.output_charset if it is unicode.
........
................
This means that what gets encoded in base64 is the encoded version of the
unicode payload. This bug was revealed by a forward port of the tests from
Issue 1368247, but the fix was completely different.
Note that the merge is only of the tests, the doc changes were inappropriate
since email5 expects unicode, not bytes. I'm also not convinced that
quopri works correctly in email5, but that's a different issue.
Merged revisions 81658 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r81658 | r.david.murray | 2010-06-02 18:03:15 -0400 (Wed, 02 Jun 2010) | 9 lines
#1368247: make set_charset/MIMEText automatically encode unicode _payload.
Fixes (mysterious, to the end user) UnicodeErrors when using utf-8 as
the charset and unicode as the _text argument. Also makes the way in
which unicode gets encoded to quoted printable for other charsets more
sane (it only worked by accident previously). The _payload now is encoded
to the charset.output_charset if it is unicode.
........
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r80795 | barry.warsaw | 2010-05-05 18:18:31 +0200 (Mi, 05 Mai 2010) | 5 lines
Bug 7755: audiotest.au is arguably copyrighted material, but definitely makes
Debian unhappy. The actual contents of the audio clip are unimportant, so
replace it with something that we know is okay. Guido likes woodpeckers.
........
svn+ssh://pythondev@svn.python.org/python/branches/py3k
................
r79996 | r.david.murray | 2010-04-12 10:48:58 -0400 (Mon, 12 Apr 2010) | 15 lines
Merged revisions 79994 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r79994 | r.david.murray | 2010-04-12 10:26:06 -0400 (Mon, 12 Apr 2010) | 9 lines
Issue #7472: ISO-2022 charsets now consistently use 7bit CTE.
Fixed a typo in the email.encoders module so that messages output using
an ISO-2022 character set will use a content-transfer-encoding of
7bit consistently. Previously if the input data had any eight bit
characters the output data would get marked as 8bit even though it
was actually 7bit.
........
................
r80855 | r.david.murray | 2010-05-05 21:41:14 -0400 (Wed, 05 May 2010) | 24 lines
Merged revisions 80800 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
It turns out that email5 (py3k), because it is using unicode for the
payload, doesn't do the encoding to the output character set until later
in the process. Specifically, charset.body_encode no longer does the
input-to-output charset conversion. So the if test in the exception
clause in encoders.encode_7or8bit really is needed in email5.
So, this merge only merges the test, not the removal of the 'if'.
........
r80800 | r.david.murray | 2010-05-05 13:31:03 -0400 (Wed, 05 May 2010) | 9 lines
Issue #7472: remove unused code from email.encoders.encode_7or8bit.
Yukihiro Nakadaira noticed a typo in encode_7or8bit that was trying
to special case iso-2022 codecs. It turns out that the code in
question is never used, because whereas it was designed to trigger
if the payload encoding was eight bit but its output encoding was
7 bit, in practice the payload is always converted to the 7bit
encoding before encode_7or8bit is called. Patch by Shawat Anand.
........
................
svn+ssh://pythondev@svn.python.org/python/trunk
It turns out that email5 (py3k), because it is using unicode for the
payload, doesn't do the encoding to the output character set until later
in the process. Specifically, charset.body_encode no longer does the
input-to-output charset conversion. So the if test in the exception
clause in encoders.encode_7or8bit really is needed in email5.
So, this merge only merges the test, not the removal of the 'if'.
........
r80800 | r.david.murray | 2010-05-05 13:31:03 -0400 (Wed, 05 May 2010) | 9 lines
Issue #7472: remove unused code from email.encoders.encode_7or8bit.
Yukihiro Nakadaira noticed a typo in encode_7or8bit that was trying
to special case iso-2022 codecs. It turns out that the code in
question is never used, because whereas it was designed to trigger
if the payload encoding was eight bit but its output encoding was
7 bit, in practice the payload is always converted to the 7bit
encoding before encode_7or8bit is called. Patch by Shawat Anand.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r79994 | r.david.murray | 2010-04-12 10:26:06 -0400 (Mon, 12 Apr 2010) | 9 lines
Issue #7472: ISO-2022 charsets now consistently use 7bit CTE.
Fixed a typo in the email.encoders module so that messages output using
an ISO-2022 character set will use a content-transfer-encoding of
7bit consistently. Previously if the input data had any eight bit
characters the output data would get marked as 8bit even though it
was actually 7bit.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r78018 | georg.brandl | 2010-02-06 11:08:21 +0100 (Sa, 06 Feb 2010) | 1 line
#7864: make deprecation notices a bit clearer.
........
r78035 | georg.brandl | 2010-02-06 23:44:17 +0100 (Sa, 06 Feb 2010) | 1 line
Fix duplicate import.
........
r78036 | georg.brandl | 2010-02-06 23:49:47 +0100 (Sa, 06 Feb 2010) | 1 line
Remove unused import.
........
r78037 | georg.brandl | 2010-02-06 23:59:15 +0100 (Sa, 06 Feb 2010) | 1 line
No need to assign the results of expressions used only for side effects.
........
r78038 | georg.brandl | 2010-02-07 00:02:29 +0100 (So, 07 Feb 2010) | 1 line
Add a missing import.
........
r78039 | georg.brandl | 2010-02-07 00:06:24 +0100 (So, 07 Feb 2010) | 1 line
Add missing imports.
........
r78040 | georg.brandl | 2010-02-07 00:08:00 +0100 (So, 07 Feb 2010) | 1 line
Fix a few UnboundLocalErrors in test_long.
........
r78042 | georg.brandl | 2010-02-07 00:12:12 +0100 (So, 07 Feb 2010) | 1 line
Add missing import.
........
r78043 | georg.brandl | 2010-02-07 00:12:19 +0100 (So, 07 Feb 2010) | 1 line
Remove duplicate test method.
........
r78046 | georg.brandl | 2010-02-07 00:18:00 +0100 (So, 07 Feb 2010) | 1 line
Fix various missing import/unbound name errors.
........
r78048 | georg.brandl | 2010-02-07 00:23:45 +0100 (So, 07 Feb 2010) | 1 line
We heard you like test failures so we put unbound locals in your test so that you can fail while you fail.
........
r78049 | georg.brandl | 2010-02-07 00:33:33 +0100 (So, 07 Feb 2010) | 1 line
Fix import/access for some identifiers. _TestSharedCTypes does not seem to be executed?
........
r78050 | georg.brandl | 2010-02-07 00:34:10 +0100 (So, 07 Feb 2010) | 1 line
Fix more unbound locals in code paths that do not seem to be used.
........
r78051 | georg.brandl | 2010-02-07 00:53:52 +0100 (So, 07 Feb 2010) | 1 line
Add missing import when running these tests standalone.
........
r78052 | georg.brandl | 2010-02-07 00:54:04 +0100 (So, 07 Feb 2010) | 1 line
Add missing import when running these tests standalone.
........
r78054 | georg.brandl | 2010-02-07 00:58:25 +0100 (So, 07 Feb 2010) | 1 line
Add missing import.
........
r78059 | georg.brandl | 2010-02-07 12:34:15 +0100 (So, 07 Feb 2010) | 1 line
Use "regexp" consistently.
........
r78075 | georg.brandl | 2010-02-07 13:16:12 +0100 (So, 07 Feb 2010) | 1 line
Fix another duplicated test method.
........
r78076 | georg.brandl | 2010-02-07 13:19:43 +0100 (So, 07 Feb 2010) | 1 line
Fix wrong usage of "except X, Y:".
........
r78077 | georg.brandl | 2010-02-07 13:25:50 +0100 (So, 07 Feb 2010) | 1 line
Fix two redefined test methods.
........
r78078 | georg.brandl | 2010-02-07 13:27:06 +0100 (So, 07 Feb 2010) | 1 line
Fix a redefined test method.
........
r78079 | georg.brandl | 2010-02-07 13:34:26 +0100 (So, 07 Feb 2010) | 1 line
Add a minimal test for fnmatchcase().
........
r78080 | georg.brandl | 2010-02-07 13:55:12 +0100 (So, 07 Feb 2010) | 1 line
Remove duplicate test method.
........
the trunk patch, and removes the last trace of bdecode, which was
a commented out call in message.py.
Merged revisions 78778 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r78778 | r.david.murray | 2010-03-07 21:04:06 -0500 (Sun, 07 Mar 2010) | 9 lines
Issue #7143: get_payload used to strip any trailing newline from a
base64 transfer-encoded payload *after* decoding it; it no longer does.
email had a special method in utils, _bdecode, specifically to do this,
so it must have served a purpose at some point, yet it is clearly wrong
per RFC. Fixed with Barry's approval, but no backport. Email package
minor version number is bumped, now version 4.0.1.
Patch by Joaquin Cuenca Abela.
........
svn+ssh://pythondev@svn.python.org/python/branches/py3k
................
r78276 | r.david.murray | 2010-02-20 23:39:40 -0500 (Sat, 20 Feb 2010) | 16 lines
Merged revisions 78274 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r78274 | r.david.murray | 2010-02-20 23:23:00 -0500 (Sat, 20 Feb 2010) | 9 lines
Issue 7970: When email.Parser.Parser parses a MIME message of type
message/rfc822 it turns it into an object whose body consists of
a list containing a single Message object. HeaderParser, on the
other hand, just copies the body as a string. Generator.flatten
has a special handler for the message mime type that expected the
body to be the one item list. This fails if the message was parsed
by HeaderParser. So we now check to see if the body is a string
first, and if so just we just emit it.
........
................
svn+ssh://pythondev@svn.python.org/python/trunk
........
r78274 | r.david.murray | 2010-02-20 23:23:00 -0500 (Sat, 20 Feb 2010) | 9 lines
Issue 7970: When email.Parser.Parser parses a MIME message of type
message/rfc822 it turns it into an object whose body consists of
a list containing a single Message object. HeaderParser, on the
other hand, just copies the body as a string. Generator.flatten
has a special handler for the message mime type that expected the
body to be the one item list. This fails if the message was parsed
by HeaderParser. So we now check to see if the body is a string
first, and if so just we just emit it.
........
svn+ssh://pythondev@svn.python.org/python/branches/py3k
................
r77542 | r.david.murray | 2010-01-16 13:30:03 -0500 (Sat, 16 Jan 2010) | 18 lines
Merged revisions 77517,77525 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
Merge adds an additional test for as_string with a maxheaderlen specified.
........
r77517 | r.david.murray | 2010-01-16 00:15:17 -0500 (Sat, 16 Jan 2010) | 6 lines
Issue #1670765: Prevent email.generator.Generator from re-wrapping
headers in multipart/signed MIME parts, which fixes one of the sources of
invalid modifications to such parts by Generator. Patch and tests by
Martin von Gagern.
........
r77525 | r.david.murray | 2010-01-16 11:08:32 -0500 (Sat, 16 Jan 2010) | 2 lines
Fix issue number in comment.
........
................
svn+ssh://pythondev@svn.python.org/python/trunk
Merge adds an additional test for as_string with a maxheaderlen specified.
........
r77517 | r.david.murray | 2010-01-16 00:15:17 -0500 (Sat, 16 Jan 2010) | 6 lines
Issue #1670765: Prevent email.generator.Generator from re-wrapping
headers in multipart/signed MIME parts, which fixes one of the sources of
invalid modifications to such parts by Generator. Patch and tests by
Martin von Gagern.
........
r77525 | r.david.murray | 2010-01-16 11:08:32 -0500 (Sat, 16 Jan 2010) | 2 lines
Fix issue number in comment.
........
R David Murray
Florent Xicluna
Ezio Melotti
Nick Coghlan
Antoine Pitrou
Georg Brandl
Victor Stinner
Brett Cannon
Matthias Klose
Barry Warsaw
Benjamin Peterson