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, mgdelmonte, r.david.murray
Date 2015-06-03.00:48:34
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
No, the point is to do "best practical" error recovery when faced with dirty data that may be dirty in various ways, and it doesn't really matter whether it is http headers or email headers.  A line with leading whitespace is treated as part of the preceding header line now, and this is the way it should behave, since the older http standards adopted that behavior from rfc822.  You will note that the standard referenced by Ian is explicit about that, in the obs-fold clause.  That is, we are required by the standard to support that behavior, which is why I posit that the best recovery is to assume an invalid line followed by what look like headers is in fact an incorrectly folded obs-fold continuation line.  That this will also conform to the email standard is a not-accidental consequence of how these standards evolved.  (That is, email and http header handling are *not* "different" specs in the sense of being disjoint, they are derivatives of a common ancestor spec and some effort is spent keeping them interoperable, to my understanding.)
Date User Action Args
2015-06-03 00:48:35r.david.murraysetrecipients: + r.david.murray, barry, icordasc, demian.brecht, Lukasa, mgdelmonte
2015-06-03 00:48:35r.david.murraysetmessageid: <>
2015-06-03 00:48:35r.david.murraylinkissue24363 messages
2015-06-03 00:48:34r.david.murraycreate