[issue23434] support encoded filename in Content-Disposition for HTTP in cgi.FieldStorage

And Clover added the comment: > Are you saying there is no (http) RFC compliant way to fix this Sadly, yes. And though RFCs aren't always a fair representation of real-world use, RFC 7578 is informative as well as normative: at present nothing produces "filename*=" in multipart/form-data.

[issue23434] support encoded filename in Content-Disposition for HTTP in cgi.FieldStorage

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue23434] support encoded filename in Content-Disposition for HTTP in cgi.FieldStorage

R. David Murray added the comment: Are you saying there is no (http) RFC compliant way to fix this, or no way to fix it with the email library parsers? If the latter, the library is pretty flexible and for internal stdlib use it would probably be permissible to directly call methods in the

[issue23434] support encoded filename in Content-Disposition for HTTP in cgi.FieldStorage

And Clover added the comment: HTTP generally isn't an RFC 822-family standard. Its headers look a lot like it, but they have their own defined syntax that differs in niggling little details. Using mail parsing code for HTTP isn't usually the right thing. HTTP has always used its own syntax d

[issue23434] support encoded filename in Content-Disposition for HTTP in cgi.FieldStorage

R. David Murray added the comment: I haven't read the http rfcs, but my understanding is that they follow the MIME standards, and the email library already has code to do proper parsing and decoding of encoded filenames in Content-Disposition headers. It should be possible to call that code

[issue23434] support encoded filename in Content-Disposition for HTTP in cgi.FieldStorage

Paweł added the comment: I didn't find this and created a duplicate https://bugs.python.org/issue33027 I've added similar/updated changes https://github.com/python/cpython/pull/6027 @r.david.murray wouldn't it be wise to do one step at a time rather than implementing full support for RFC6266?