This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author r.david.murray
Recipients barry, brokenenglish, martin.panter, r.david.murray
Date 2017-04-05.11:36:15
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1491392175.23.0.615386786796.issue29353@psf.upfronthosting.co.za>
In-reply-to
Content
I'm not surprised that trying to render a message parsed with 'headersonly' fails.  headersonly treats the entire message body as a single string payload.  I'm not sure what the correct behavior should be for the email package, but the fact that this doesn't work currently shouldn't matter to the http package.  Given the error involves policy, it is quite possible as_string used to work in this context and I broke it when introducing policy because there is no test that covers this case.  I'm guessing there is no test because turning a message parsed with headersonly back into a string wasn't considered to be useful.

As for the multipart thing, that is actually consistent with the docs.  get_content_type gives you the value of the header, is_multipart effectively reports whether or not the payload is a list, and when parsed with headersonly, the body is a string not a list, which is documented.  Granted, you have to connect those dots yourself, so a sentence about that *could* be added to the headersonly docs.

All of which should be in a separate issue from this one.
History
Date User Action Args
2017-04-05 11:36:15r.david.murraysetrecipients: + r.david.murray, barry, martin.panter, brokenenglish
2017-04-05 11:36:15r.david.murraysetmessageid: <1491392175.23.0.615386786796.issue29353@psf.upfronthosting.co.za>
2017-04-05 11:36:15r.david.murraylinkissue29353 messages
2017-04-05 11:36:15r.david.murraycreate