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 karlcow, orsenthil, r.david.murray
Date 2013-03-04.13:40:02
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1362404403.17.0.167433730114.issue17322@psf.upfronthosting.co.za>
In-reply-to
Content
A crazy idea that occurred to me was to create an "rfc822-style-header management" module, and share it between email, http, and urllib.  We'd probably break too many things backward-compatibility wise if we did that, but I still think it is an interesting thought :)

On the other hand, having thought about this particular issue some more: in the email package we have the constraint of needing to be able to exactly reproduce the input data, whereas in the http world that constraint does not apply.  So in the http world, given that headers are *already* being transformed by the code in question (title casing), it seems reasonable that blank stripping also be done, even just from an API standpoint.

Really I guess the only question is how likely this is to break existing code.  I'm pretty sure it is small enough that doing this in 3.4 would be fine, but I don't know how to estimate if it is small enough to also change it in maintenance releases.  Since this particular bit is a new standard, maybe we just go with 3.4?
History
Date User Action Args
2013-03-04 13:40:03r.david.murraysetrecipients: + r.david.murray, orsenthil, karlcow
2013-03-04 13:40:03r.david.murraysetmessageid: <1362404403.17.0.167433730114.issue17322@psf.upfronthosting.co.za>
2013-03-04 13:40:03r.david.murraylinkissue17322 messages
2013-03-04 13:40:02r.david.murraycreate