On 1/20/2011 12:58 PM, Dennis Lee Bieber wrote:
I'd first be concerned about the absence of the line ending sequence
specified by the RFC: carriage return (CR; \r) followed by line feed
(LF; \n).
I realized after I posted the original message that this might distract
from the issue I'm asking about. The module is a little sloppy about
its own generation of CRLF tokens when it serializes messages (it leaves
the insertion of the CR to processing further downstream), and I was
mimicking that behavior in what I fed to the method in my example. I
should have avoided that problem and included the \r. Let's pretend
that I did: the behavior is unaffected by the absence or presence of the
CR character.
...
However, the module does appear to trim leading whitespace that
occurs between the : and text (and the line end is considered for that
trimming, but not any whitespace after it).
Exactly. I'm focusing on the word "equivalent" in the RFC. Either the
module is going to strip leading white space from the value or it's
not. Returning different values for the unwrapped header, depending on
whether wrapping was present, is failing to treat the two sequences as
equivalent. Logically, the processing sequence should be:
1. Unwrap the header ("Subject:\r\n foo" becomes "Subject: foo")
2. Trim leading white space (" foo" becomes "foo")
Ideally, the behavior of trimming the leading white space would be
reflected documentation (but it isn't).
--
Bob Kline
http://www.rksystems.com
mailto:bkl...@rksystems.com
--
http://mail.python.org/mailman/listinfo/python-list
