Commit Graph

12 Commits

Author SHA1 Message Date
Barry Warsaw bb26b4530b Parser.__init__(): The consensus on the mimelib-devel list is that
non-strict parsing should be the default.  Make it so.
2002-07-19 22:25:34 +00:00
Barry Warsaw 7aeac9180e Anthony Baxter's cleanup patch. Python project SF patch # 583190,
quoting:

  in non-strict mode, messages don't require a blank line at the end
  with a missing end-terminator. A single newline is sufficient now.

  Handle trailing whitespace at the end of a boundary. Had to switch
  from using string.split() to re.split()

  Handle whitespace on the end of a parameter list for Content-type.

  Handle whitespace on the end of a plain content-type header.

Specifically,

get_type(): Strip the content type string.

_get_params_preserve(): Strip the parameter names and values on both
sides.

_parsebody(): Lots of changes as described above, with some stylistic
changes by Barry (who hopefully didn't screw things up ;).
2002-07-18 23:09:09 +00:00
Barry Warsaw f6caeba03a Anthony Baxter's patch for non-strict parsing. This adds a `strict'
argument to the constructor -- defaulting to true -- which is
different than Anthony's approach of using global state.

parse(), parsestr(): Grow a `headersonly' argument which stops parsing
once the header block has been seen, i.e. it does /not/ parse or even
read the body of the message.  This is used for parsing message/rfc822
type messages.

We need test cases for the non-strict parsing.  Anthony will supply
these.

_parsebody(): We can get rid of the isdigest end-of-line kludges,
although we still need to know if we're parsing a multipart/digest so
we can set the default type accordingly.
2002-07-09 02:50:02 +00:00
Barry Warsaw 69e18af968 _parsebody(): Fix for the new message/rfc822 tree structure (the
parent is now a multipart with one element, the sub-message object).
2002-06-02 19:12:03 +00:00
Barry Warsaw 7e21b6792b I've thought about it some more, and I believe it is proper for the
email package's Parser to handle the three common line endings.
Certain protocols such as IMAP define CRLF line endings and it doesn't
make sense for the client app to have to normalize the line endings
before handing it message off to the Parser.

_parsebody(): Be more flexible in the matching of line endings for
finding the MIME separators.  Accept any of \r, \n and \r\n.  Note
that we do /not/ change the line endings in the payloads, we just
accept any of those three around MIME boundaries.
2002-05-19 23:51:50 +00:00
Barry Warsaw 409a4c08b5 Sync'ing with standalone email package 2.0.1. This adds support for
non-us-ascii character sets in headers and bodies.  Some API changes
(with DeprecationWarnings for the old APIs).  Better RFC-compliant
implementations of base64 and quoted-printable.

Updated test cases.  Documentation updates to follow (after I finish
writing them ;).
2002-04-10 21:01:31 +00:00
Barry Warsaw 15e9dc9eac _parsebody(): When adding subparts to a multipart container, make sure
that the first subpart added makes the payload a list object.
Otherwise, a multipart/* with only one subpart will not have the
proper structure.
2002-01-27 06:48:02 +00:00
Barry Warsaw e552882960 HeaderParser: A new subclass of Parser which only parses the message
headers.  It does not parse the body of the message, instead simply
assigning it as a string to the container's payload.  This can be much
faster when you're only interested in a message's header.
2001-10-11 15:43:00 +00:00
Barry Warsaw e968ead1dd Give me back my page breaks. 2001-10-04 17:05:11 +00:00
Tim Peters 527e64fd68 Whitespace normalization. 2001-10-04 05:36:56 +00:00
Barry Warsaw 66971fbca5 _parsebody(): Use get_boundary() and get_type().
Also, add a clause to the big-if to handle message/delivery-status
    content types.  These create a message with subparts that are
    Message instances, which best represent the header blocks of this
    content type.
2001-09-26 05:44:09 +00:00
Barry Warsaw ba92580f01 The email package version 1.0, prototyped as mimelib
<http://sf.net/projects/mimelib>.  There /are/ API differences between
mimelib and email, but most of the implementations are shared (except
where cool Py2.2 stuff like generators are used).
2001-09-23 03:17:28 +00:00