Commit Graph

16 Commits

Author SHA1 Message Date
Ezio Melotti 2623a37852 Merged revisions 86596 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/branches/py3k

........
  r86596 | ezio.melotti | 2010-11-20 21:04:17 +0200 (Sat, 20 Nov 2010) | 1 line

  #9424: Replace deprecated assert* methods in the Python test suite.
........
2010-11-21 13:34:58 +00:00
R. David Murray 75a292e5be Merged revisions 83690 via svnmerge from
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.
........
2010-08-04 00:05:50 +00:00
R. David Murray 4617e5085a 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.
2010-03-08 02:04:06 +00:00
Ezio Melotti dde5b94875 #7092: Silence more py3k warnings. Patch by Florent Xicluna. 2010-02-03 05:37:26 +00:00
Antoine Pitrou af45b11527 Kill a couple of "<>" 2010-01-04 23:28:16 +00:00
Benjamin Peterson 5c8da86f3a convert usage of fail* to assert* 2009-06-30 22:57:08 +00:00
Barry Warsaw dbf95a3643 A fix for issue 1974, inspired by the patch from Andi Albrecht (aalbrecht),
though with some changes by me.  This patch should not be back ported or
forward ported.  It's a bit too risky for 2.6 and 3.x does things fairly
differently.
2009-03-30 22:42:17 +00:00
Barry Warsaw 81a06d4260 In response to this SF bug:
[ 1752723 ] email.message_from_string: initial line gets discarded

I added a test to assert that when the first line of text passed to
message_from_string() contains a leading space, the message ends up with the
appropriate FirstHeaderLineIsContinuationDefect on its defects list.

The bug is invalid.
2007-07-13 22:12:58 +00:00
Barry Warsaw dcd24ae501 SF bug #1582282; decode_header() incorrectly splits not-conformant RFC
2047-like headers where there is no whitespace between encoded words.  This
fix changes the matching regexp to include a trailing lookahead assertion that
the closing ?= must be followed by whitespace, newline, or end-of-string.
This also changes the regexp to add the MULTILINE flag.
2007-03-14 04:59:50 +00:00
Barry Warsaw cbbc3f19c1 Tokio Kikuchi's fix for SF bug #1629369; folding whitespace allowed in the
display name of an email address, e.g.

Foo
\tBar <foo@example.com>

Test case added by Barry.
2007-03-12 03:20:01 +00:00
Barry Warsaw d92ae78bdb Forward port some fixes that were in email 2.5 but for some reason didn't make
it into email 4.0.  Specifically, in Message.get_content_charset(), handle RFC
2231 headers that contain an encoding not known to Python, or a character in
the data that isn't in the charset encoding.  Also forward port the
appropriate unit tests.
2006-07-26 05:54:46 +00:00
Barry Warsaw b110bad2d9 More RFC 2231 improvements for the email 4.0 package. As Mark Sapiro rightly
points out there are really two types of continued headers defined in this
RFC (i.e. "encoded" parameters with the form "name*0*=" and unencoded
parameters with the form "name*0="), but we were were handling them both the
same way and that isn't correct.

This patch should be much more RFC compliant in that only encoded params are
%-decoded and the charset/language information is only extract if there are
any encoded params in the segments.  If there are no encoded params then the
RFC says that there will be no charset/language parts.

Note however that this will change the return value for Message.get_param() in
some cases.  For example, whereas before if you had all unencoded param
continuations you would have still gotten a 3-tuple back from this method
(with charset and language == None), you will now get just a string.  I don't
believe this is a backward incompatible change though because the
documentation for this method already indicates that either return value is
possible and that you must do an isinstance(val, tuple) check to discriminate
between the two.  (Yeah that API kind of sucks but we can't change /that/
without breaking code.)

Test cases, some documentation updates, and a NEWS item accompany this patch.
2006-07-21 14:51:07 +00:00
Barry Warsaw 18d2f39af7 decode_rfc2231(): Be more robust against buggy RFC 2231 encodings.
Specifically, instead of raising a ValueError when there is a single tick in
the parameter, simply return that the entire string unquoted, with None for
both the charset and the language.  Also, if there are more than 2 ticks in
the parameter, interpret the first three parts as the standard RFC 2231 parts,
then the rest of the parts as the encoded string.

Test cases added.

Original fewer-than-3-parts fix by Tokio Kikuchi.

Resolves SF bug # 1218081.  I will back port the fix and tests to Python 2.4
(email 3.0) and Python 2.3 (email 2.5).

Also, bump the version number to email 4.0.1, removing the 'alpha' moniker.
2006-07-17 23:07:51 +00:00
Barry Warsaw dbcc8d9b24 Port forward from 2.4 branch:
Patch #1464708 from William McVey: fixed handling of nested comments in mail
addresses.  E.g.

"Foo ((Foo Bar)) <foo@example.com>"

Fixes for both rfc822.py and email package.  This patch needs to be back
ported to Python 2.3 for email 2.5.
2006-05-01 03:03:02 +00:00
Anthony Baxter 93f5b93422 The email module's parsedate_tz function now sets the daylight savings
flag to -1 (unknown) since it can't tell from the date whether it should
be set.
patch from Aldo Cortesi
2006-04-03 08:05:07 +00:00
Barry Warsaw 40ef0067ad Merge email package 4.0 from the sandbox, including documentation, test cases,
and NEWS updates.
2006-03-18 15:41:53 +00:00