[ python-Bugs-1072623 ] FeedParser problem on end boundaries w/o newline

SourceForge.net noreply at sourceforge.net
Sun Nov 28 01:21:44 CET 2004


Bugs item #1072623, was opened at 2004-11-24 12:27
Message generated for change (Settings changed) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072623&group_id=5470

Category: Python Library
>Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Tessa Lau (tlau)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: FeedParser problem on end boundaries w/o newline

Initial Comment:
(Python 2.3.4, Linux Debian unstable)

The email module's as_string() method generates
messages that do not include a trailing CRLF on the
last line.  This causes problems when Python-created
messages are piped to procmail and delivered to an mbox.

The attached test script illustrates this behavior. 
You must have a working procmail configured to deliver
mail to an mbox (the default configuration will work).
 If you then read the resulting mailbox with /bin/mail,
it appears as if there is only one message in the
mailbox, instead of two.  The second is concatenated on
to the end of the first.  The mbox does not contain a
blank line between the first message and the second. 
Pop servers require this blank line delimiter between
messages.

You could argue that this is procmail's responsibility,
but as far as I can tell from reading RFC 2822, each
line in an email message must terminate in CRLF, and
Python's email module is violating that spec.

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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2004-11-27 19:03

Message:
Logged In: YES 
user_id=12800

Changing the summary of this issue to reflect the real
problem.   The attachment 1072623.py illustrates that if the
end boundary of a string being parsed by the FeedParser does
not have a trailing newline, the parser doesn't recognize
this as an end boundary.  It just so happens that your
example produces a message string with that property (which
isn't a bug).

The fix is about as trivial as you can get: one character.


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

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


More information about the Python-bugs-list mailing list