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 bpoaugust
Recipients barry, bpoaugust, r.david.murray
Date 2016-12-24.10:41:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1482576061.0.0.10946762523.issue29020@psf.upfronthosting.co.za>
In-reply-to
Content
Another case is get_filename.

The second call to unquote will only change the incoming parameter if the original value was enclosed in <> or "". This is not a common scenario, and was only discovered because a mailer used the form <<<abcd>>> as a boundary marker (yes, this is invalid). So existing tests are unlikely to notice any difference.

Note that it is wrong to unquote more times than the original value has been quoted. So the only possible reason for keeping unquote in the function is if unquote has not already been called on a quoted value. (It is not possible to tell from the parameter whether or not it is currently quoted).

The two sample callers are get_boundary and get_filename.
Both pass the value already unquoted.

This method should be fixed to remove the unquote calls.
If there is a caller (is there one?) that does not unquote the value first, then that needs to be fixed as well.
History
Date User Action Args
2016-12-24 10:41:01bpoaugustsetrecipients: + bpoaugust, barry, r.david.murray
2016-12-24 10:41:00bpoaugustsetmessageid: <1482576061.0.0.10946762523.issue29020@psf.upfronthosting.co.za>
2016-12-24 10:41:00bpoaugustlinkissue29020 messages
2016-12-24 10:41:00bpoaugustcreate