[issue24764] cgi.FieldStorage can't parse multipart part headers with Content-Length and no filename in Content-Disposition

Peter Landry added the comment: Pradeep, that error seems to be in Barbican. This bug and patch only addresses content-length headers in MIME multipart messages. -- ___ Python tracker <http://bugs.python.org/issue24

[issue24764] cgi.FieldStorage can't parse multipart part headers with Content-Length and no filename in Content-Disposition

Peter Landry added the comment: A new patch that simply removes Content-Length from part headers when present. -- Added file: http://bugs.python.org/file40145/cgi_multipart.patch ___ Python tracker <http://bugs.python.org/issue24

[issue24764] cgi.FieldStorage can't parse multipart part headers with Content-Length and no filename in Content-Disposition

Peter Landry added the comment: Yeah, I think that makes the most sense to me as well. I tried to make a minimum-impact patch, but this feels cleaner. If we remove the Content-Length header, the `limit` kwarg might occur at an odd place in the part itself, but that feels unavoidable if

[issue24764] cgi.FieldStorage can't parse multipart part headers with Content-Length and no filename in Content-Disposition

New submission from Peter Landry: `cgi.FieldStorage` can't parse a multipart with a `Content-Length` header set on a part: ```Python 3.4.3 (default, May 22 2015, 15:35:46) [GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.49)] on darwin Type "help", "copyright", &

[issue24764] cgi.FieldStorage can't parse multipart part headers with Content-Length and no filename in Content-Disposition

Peter Landry added the comment: I realized my formatting was poor, making it hard to quickly test the issue. Here's a cleaner version: import cgi from io import BytesIO BOUNDARY = "JfISa01" POSTDATA = """--JfISa01 Content-Disposition