Description of problem:
This is a request to backport the following bugfix.
Upstream bug: http://bugs.python.org/issue7082
message.get_filename() in python email incorrectly looks for a "name" parameter in Content-Disposition header when it does not find a "filename" parameter. This is wrong, since there is no such defined parameter. Instead, there is a "name" parameter in Content-Type header, which ought to be checked in case the "filename" parameter in content-Disposition does not exist.
* The issue impacts the customer of our customer, hence they need an urgent fix for this.
* The fix is trivial, but may be viewed as a behaviour change and hence not recommended for RHEL-5
* The "name" parameter for Content-Type is apparently deprecated:
but a number of applications still use it (Microsoft's .Net framework) and hence needs to be supported.
Version-Release number of selected component (if applicable):
message.get_filename() in python email incorrectly looks for a "name" parameter in Content-Disposition header when it does not find a "filename" parameter
Content-Type header should be checked
svn co http://svn.python.org/projects/python/trunk python
svn diff -r75300:75301
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
The email module incorrectly implemented the logic for obtaining attachment filenames: the get_filename() fallback for using the deprecated "name" parameter of the "Content-Type" header erroneously used the "Content-Disposition" header. This update backports a fix from Python 2.6, which resolves this issue.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.