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 Lukasa, barry, demian.brecht, icordasc, martin.panter, mgdelmonte, r.david.murray
Date 2015-06-03.01:25:08
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1433294709.29.0.524192632917.issue24363@psf.upfronthosting.co.za>
In-reply-to
Content
Since the email package has the correct logic for handling the blank continuation line case (even in Python2) (because, again, that derives from the original email standard), it might be reasonable to use feedparser's headersonly mode.  If necessary we can introduce a (private) variation that actually stops parsing the stream at the end of the headers.  (This would be a non-public API on feedparser for 2.7 and 3.4/5, and a public one in 3.6.)  Since feedparser was itself a rewrite of the mimetools code httplib is using and theoretically backward compatible with it in behavior, this should not in theory introduce any behavior changes (famous last words?).  

The problem here is the good chance that someone is depending on the internal implementation of HTTPMessage.  So, I'm not at all sure about this suggestion.
 
And yes, the email package in python3 records header defects.  However, I think it is better to treat the no-leading-blank non-header as an incorrectly folded continuation line rather than discarding the data.  The data is in the headers section for *some* reason, and IMO that is the only reasonable guess as to why.
History
Date User Action Args
2015-06-03 01:25:09r.david.murraysetrecipients: + r.david.murray, barry, martin.panter, icordasc, demian.brecht, Lukasa, mgdelmonte
2015-06-03 01:25:09r.david.murraysetmessageid: <1433294709.29.0.524192632917.issue24363@psf.upfronthosting.co.za>
2015-06-03 01:25:09r.david.murraylinkissue24363 messages
2015-06-03 01:25:08r.david.murraycreate