Sergey Schetinin added the comment:
I don't think that's a security issue, just something that would break with
certain filenames. And I said that it's a browsers' problem in the sense that
it can only be fixed /
Sergey Schetinin added the comment:
I wanted to add that the fact that browsers encode the field names in the page
encoding does not change that they should escape the header according to RFC
2047.
The percent-encoding used in the field name has nothing to do with
multipart/form-data or
Sergey Schetinin added the comment:
It does work (Python 2.7.1 here):
>>> import cgi
>>> cgi.parse_header('Content-Disposition: form-data; name=""%22"')
('Content-Disposition: form-data', {'name': '"%22'})
&
Sergey Schetinin added the comment:
I've dug into the RFCs and tested various browsers.
RFC 2388 (the one defining multipart/form-data) says:
Field names originally in non-ASCII character sets may be encoded
within the value of the "name" parameter using the standard method
d
Sergey Schetinin added the comment:
And here's a patch.
--
keywords: +patch
Added file: http://bugs.python.org/file20820/cgi-patch.patch
___
Python tracker
<http://bugs.python.org/is
New submission from Sergey Schetinin :
Tested on Python 2.7, but probably affects all versions. Test case is attached.
The reason this went unnoticed until now is that browsers are very conservative
when quoting field names, so most field names are the same after their quoting.
Related bug in
