summaryrefslogtreecommitdiffstats
path: root/Lib/email/test
Commit message (Collapse)AuthorAgeFilesLines
* Fix the tests to work with Python 2.1, which email 2.5 must do.Barry Warsaw2006-07-261-4/+4
|
* Back port r50693 and r50754 from the trunk (and 2.4 branch):Barry Warsaw2006-07-251-13/+138
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. 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. Original fewer-than-3-parts fix by Tokio Kikuchi. Resolves SF bug # 1218081. Also, bump the package version number to 2.5.8 for release.
* Back port from 2.4 branch:Barry Warsaw2006-05-011-0/+6
| | | | | | | | | 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.
* Resolve SF bug 1409403: email.Message should supress warning from uu.decode.Barry Warsaw2006-02-091-0/+13
| | | | | | | | However, the patch in that tracker item is elaborated such that the newly included unit test pass on Python 2.1 through 2.5. Note that Python 2.1's uu.decode() does not have a 'quiet' argument, so we have to be sneaky. Will port to email 3.0 (although without the backward compatible sneakiness).
* Patches to address SF bugs 1409538 (Japanese codecs in CODEC_MAP) and 1409455Barry Warsaw2006-02-082-6/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | (.set_payload() gives bad .get_payload() results). Specific changes include: Simplfy the default CODEC_MAP in Charset.py to not include the Japanese and Korean codecs. The names of the codecs are different depending on whether you're using Python 2.4 and 2.5, which include the codecs by default, or earlier Python's which provide the codecs under different names as a third party library. Now, we attempt to discover which (if either) is available and populate the CODEC_MAP as appropriate. Message.set_charset(): When the message does not already have a Content-Transfer-Encoding header, instead of just adding the header, we also encode the body as defined by the assigned Charset. As before, if the body_encoding is callable, we just call that. If not, then we add a call to body_encode() before setting the header. This way, we guarantee that a message's text payload is always encoded properly. Remove the payload encoding code from Generator._handle_text(). With the above patch, this would cause the body to be doubly encoded. Doing this in the Message class is better than only doing it in the Generator. Added some new tests to ensure everything works correctly. Also changed the way the test_email_codecs.py tests get added (using the same lookup code that the CODEC_MAP adjustments use). This resolves both issues for email 2.5/Python 2.3. I will patch forward to email 3.0 for both Python 2.4 and 2.5.
* Resolves SF bug #1423972.Barry Warsaw2006-02-041-2/+4
|
* parsedate_tz(): Return a 1 in the tm_yday field so that the value isBarry Warsaw2006-02-031-2/+11
| | | | | | | | | | acceptable to Python 2.4's time.strftime(). This fix mirrors the behavior in email 3.0. That field is documented as being "not useable" so it might as well not be buggy too <wink>. Add a test for this behavior and update a few tests that were expecting a 0 in this field. After committing I will run the entire Python 2.3 test suite to ensure this doesn't break any Python tests.
* SF bug #1403349 solution for email 2.5; some MUAs use the 'file' parameterBarry Warsaw2006-01-172-1/+43
| | | | | | | | | | name in the Content-Distribution header, so Message.get_filename() should fall back to using that. Will port both to email 3.0 and Python 2.5 trunk. Also, bump the email package version to 2.5.7 for eventual release. Of course, add a test case too. XXX Need to update the documentation.
* get_filename(), get_content_charset(): It's possible that the charset named inBarry Warsaw2005-04-291-1/+45
| | | | | | | | | | | | | an RFC 2231-style header could be bogus or unknown to Python. In that case, we return the the text part of the parameter undecoded. However, in get_content_charset(), if that is not ascii, then it is an illegal charset and so we return failobj. Test cases and a version bump are included. Committing this to the Python 2.3 branch because I need to generate an email 2.5.6 release that contains these patches. I will port these fixes to Python 2.4 and 2.5 for email 3.x.
* test_boundary_with_leading_space(): Test case for SF bug #1060941. RFC 2046Barry Warsaw2004-11-061-0/+19
| | | | says boundaries may begin -- but not end -- with whitespace.
* Test cases and fixes for bugs described in patch #873418: email/Message.py:Barry Warsaw2004-08-161-0/+12
| | | | | | del_param fails when specifying a header. I'll port this to Python 2.4 shortly.
* Added a sample message for the test for SF bug # 846938. I'm naming thisBarry Warsaw2004-05-131-0/+10
| | | | | msg_40.txt because msg_3[6-9].txt are already used in email3/py2.4 and I'm going to forward port this test.
* test_boundary_in_non_multipart(): Added a test for SF bug # 846938.Barry Warsaw2004-05-131-0/+15
|
* test_mime_attachments_in_constructor(): New test to check for SF bug # 884030.Barry Warsaw2004-05-091-0/+9
|
* test_get_param_with_semis_in_quotes(): Test case for SF bug #794466.Barry Warsaw2003-09-031-0/+7
| | | | Backport candidate.
* Backporting email 2.5.4 fixes from the trunk.Barry Warsaw2003-08-191-0/+37
|
* A couple of new parsedate test cases.Barry Warsaw2003-05-081-0/+10
|
* Get rid of some hard coded tabsBarry Warsaw2003-04-241-3/+3
|
* test_whitespace_eater_unicode_2(): Test case for SF bug #710498.Barry Warsaw2003-03-301-0/+9
|
* test_long_lines_with_different_header(): Another test from Jason.Barry Warsaw2003-03-171-0/+16
|
* test_getaddresses_nasty(): A test for mimelib SF bug # 697641.Barry Warsaw2003-03-171-0/+10
|
* test_whitespace_eater_unicode(): Make this test Python 2.1 compatible.Barry Warsaw2003-03-121-1/+4
|
* Adjust tests for no newline appending to MIMEText.__init__()'s _textBarry Warsaw2003-03-111-2/+0
| | | | argument.
* Adjust tests for no newline appending to MIMEText.__init__()'s _textBarry Warsaw2003-03-111-11/+7
| | | | argument.
* test_get_decoded_uu_payload(): A new test forBarry Warsaw2003-03-111-0/+11
| | | | Content-Transfer-Encoding: x-uuencode
* test_escape_backslashes(): A test for SF bug #663369 by Matthew Woodcraft.Barry Warsaw2003-03-101-0/+8
|
* Fix base classBarry Warsaw2003-03-101-1/+1
|
* Use ndiffAssertEqual in a couple of places for better error reporting.Barry Warsaw2003-03-101-3/+6
|
* test_broken_base64_payload(): Test for crash in low-level binasciiBarry Warsaw2003-03-101-0/+8
| | | | module when decoding a message with broken base64.
* test_another_long_multiline_header(): Yet another formatting test.Barry Warsaw2003-03-101-0/+12
|
* test_long_unbreakable_lines_with_continuation(): Another funky exampleBarry Warsaw2003-03-071-0/+16
| | | | from Jason Mastaler :)
* test_rfc2231_no_language_or_charset(): RFC 2231 allows leaving outBarry Warsaw2003-03-071-0/+11
| | | | both the charset and language without including any single quotes.
* whitespace normalizationBarry Warsaw2003-03-071-6/+6
|
* test_string_headerinst_eq(): Another Jason test :)Barry Warsaw2003-03-071-0/+14
|
* test_long_received_header(): Another test case for folding longBarry Warsaw2003-03-061-0/+15
| | | | | Received headers (first on semis then on whitespace), given by Jason Mastaler.
* test_whitespace_eater_unicode(): Test of the last outstanding bug inBarry Warsaw2003-03-061-0/+8
| | | | SF # 640110.
* test_rfc2047_multiline(): Test case for SF bug #640110.Barry Warsaw2003-03-061-0/+14
|
* Merge of the folding-reimpl-branch. Specific changes,Barry Warsaw2003-03-062-76/+165
| | | | Update tests for email 2.5.
* Jack complained that on test_crlf_separation() was failing on MacOS9Barry Warsaw2003-01-021-4/+4
| | | | | | | | | | | | because the test file, msg_26.txt which has \r\n line endings, was getting munged by cvs, which knows to do line ending conversions for text files. But we want \r\n to be preserved on all platforms, so we cvs admin'd the file to be -kb (binary), which means we have to open the file in binary mode to preserve these line ends. Hopefully this will be the end of the thrashing on this issue (but probably not). Test passes on *nix now, and Tim confirms it passes on Windows. We'll leave it to Jack to test MacOS.
* test_bad_8bit_header(): Tests for optional argument `errors'. See SFBarry Warsaw2002-12-301-0/+11
| | | | bug #648119.
* TestMIMEAudio.setUp(): Use the email package's copy of the audio testBarry Warsaw2002-12-301-2/+7
| | | | | | file, needed because some binary distros (read RPMs) don't include the test module in their standard Python package. This eliminates an external dependency and closes SF bug # 650441.
* A copy of the audio test file from Lib/test, needed because someBarry Warsaw2002-12-301-0/+0
| | | | | | binary distros (read RPMs) don't include the test module in their standard Python package. This eliminates an external dependency and closes SF bug # 650441.
* test_parsedate_compact(): A test for optional FWS between the commaBarry Warsaw2002-12-301-0/+5
| | | | | and the day number in an RFC 2822 date specification. See bug #552345.
* test_name_with_dots(): A new test to ensure that we're implementingBarry Warsaw2002-12-301-0/+9
| | | | RFC 2822's rules w.r.t. dots in the realname part of address fields.
* test_no_separating_blank_line(): A test for SF bug #633527, noBarry Warsaw2002-11-051-16/+36
| | | | | | separating blank line between a header block and body text. Tests both lax and strict parsing.
* A message with no separating blank line between the headers and theBarry Warsaw2002-11-051-0/+4
| | | | body. A test message for SF bug #633527.
* test_text_plain_in_a_multipart_digest(): A test of the fix for SF bugBarry Warsaw2002-11-051-0/+4
| | | | | #631350, where a subobject in a multipart/digest isn't a message/rfc822.
* Test case, distilled from SF bug #631350, where a subobject in aBarry Warsaw2002-11-051-0/+19
| | | | | multipart/digest isn't a message/rfc822. This is legal, but counter to recommended practice in RFC 2046, $5.1.5.
* test_body_encoding(): a new test for Charset.body_encode(), especiallyBarry Warsaw2002-10-211-0/+14
| | | | one that tests the obscure bug reported in SF # 625509.
* test_body_encoding(): a new testBarry Warsaw2002-10-211-0/+23
|
generated by cgit v0.12 at 2025-12-26 13:31:19 (GMT)