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 v+python
Recipients amaury.forgeotdarc, barry, eric.araujo, erob, flox, ggenellina, oopos, pebbe, pitrou, quentel, r.david.murray, tcourbon, tercero12, tobias, v+python, vstinner
Date 2011-01-11.10:27:28
SpamBayes Score 0.00015959798
Marked as misclassified No
Message-id <1294741709.02.0.913998475192.issue4953@psf.upfronthosting.co.za>
In-reply-to
Content
R. David:

Pierre said:
BytesFeedParser only uses the ascii codec ; if the header has non ASCII characters (filename in a multipart/form-data), they are replaced by ? : the original file name is lost. So for the moment I leave the text version of FeedParser

I say:
Does this mean BytesFeedParser, to be useful for cgi.py, needs to accept an input parameter encoding, defaulting to ASCII for the email case?  Should that be a new issue?  Or should cgi.py, since it can't use email to do all its work (no support for file storage, no support for encoding) simply not try, and use its own code for header decoding also?  The only cost would be support for Encoded-Word -- but it is not clear that HTTP uses them?  Can anyone give an example of such?  Read the next message here for an example of filename containing non-ASCII.
History
Date User Action Args
2011-01-11 10:28:29v+pythonsetrecipients: + v+python, barry, amaury.forgeotdarc, ggenellina, pitrou, vstinner, eric.araujo, r.david.murray, oopos, tercero12, tcourbon, tobias, flox, pebbe, quentel, erob
2011-01-11 10:28:29v+pythonsetmessageid: <1294741709.02.0.913998475192.issue4953@psf.upfronthosting.co.za>
2011-01-11 10:27:28v+pythonlinkissue4953 messages
2011-01-11 10:27:28v+pythoncreate