[issue1079] decode_header does not follow RFC 2047

Tony Nelson tony_nel...@users.sourceforge.net added the comment: The email package does not follow the RFCs in anything to do with header parsing or decoding. This is a known deficiency. So no, I am not thinking of atoms at all -- and neither is email.header.decode_header()! :-( Until

[issue4487] Add utf8 alias for email charsets

Tony Nelson tony_nel...@users.sourceforge.net added the comment: This seems entirely reasonable, helpful, and in accord with the mapping of ascii to us-ascii. I recommend accepting this patch or a slightly fancier one that would also do utf_8. There are pobably other encoding names

[issue4487] Add utf8 alias for email charsets

Changes by Tony Nelson tony_nel...@users.sourceforge.net: -- versions: +Python 2.6, Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4487

[issue1079] decode_header does not follow RFC 2047

Tony Nelson tony_nel...@users.sourceforge.net added the comment: I think the problem is best viewed as headers are not being parsed according to RFC2822 and decoded after that, so the recognition of encoded words should be looser, and not require whitespace around them, as it is not required

[issue4491] email.Header.decode_header() doesn't work if encoded-word was separeted by CRLF

Tony Nelson tony_nel...@users.sourceforge.net added the comment: See patch in issue1079. I don't think email.header can require whitespace until it decodes parsed headers, as whitespace is not always required. -- nosy: +barry, tony_nelson versions: +Python 2.7

[issue1555570] email parser incorrectly breaks headers with a CRLF at 8192

Tony Nelson tony_nel...@users.sourceforge.net added the comment: The OP's diagnosis of a buffer boundary problem is correct, but incomplete. The problem can be reproduced by calling feedparser FeedParser.feed() directly, or as my patch test does, by calling BufferedSubFile.push() directly

[issue3169] email/header.py doesn't handle Base64 headers that have been insufficiently padded.

Tony Nelson tony_nel...@users.sourceforge.net added the comment: Postel's law suggests that, as bad padding can be repaired, decode_header ought to do so. The patch does that, adds a test for it, and alters another test to still properly fail on really bad encoded data. The test doesn't check

[issue3169] email/header.py doesn't handle Base64 headers that have been insufficiently padded.

Changes by Tony Nelson tony_nel...@users.sourceforge.net: -- nosy: +barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3169 ___ ___ Python-bugs

[issue5638] test_httpservers fails CGI tests if --enable-shared

New submission from Tony Nelson tony_nel...@users.sourceforge.net: test_httpservers fails the CGI tests if Python was built as a shared library (./config --enable-shared) and not yet installed. To run such a Python without installing it, the command line must define LD_LIBRARY_PATH to point

[issue1522237] _threading_local.py logic error in _localbase __new__

Tony Nelson tony_nel...@users.sourceforge.net added the comment: Thanks, Amaury. The new test works here on Python2.6.1, failing without the fix and passing with it. (Passing MyLocal(a=1) and failing MyLocal(1), as expected.) With the fix, _threading_local.py supports positional arguments

[issue5610] email feedparser.py CRLFLF bug: $ vs \Z

New submission from Tony Nelson tony_nel...@users.sourceforge.net: feedparser.py does not pares mixed newlines properly. NLCRE_eol, which is used to search for the various newlines at End Of Line, uses $ to match the end of string, but $ also matches \n$, due to a wise long-ago patch

[issue5610] email feedparser.py CRLFLF bug: $ vs \Z

Tony Nelson tony_nel...@users.sourceforge.net added the comment: make test still passes all tests except test_httpservers on my Python 2.6.1 build. The network resource was not enabled and tk is not available. The new test for CRLFLF at the end of a message body is added to Lib/email