Graham Dumpleton wrote: > >>> >>> If the size argument is made mandatory, then it would parallel how >>> read() function is defined, but this in itself would mean >>> cgi.FieldStorage would break. >>> >>> This is because cgi.FieldStorage actually calls readline() with no >>> argument as well as an argument in different places in the code. >> cgi.FieldStorage doesn't call readline() without an argument. >> cgi.parse_multipart does, but this function is not used by cgi.FieldStorage. >> I >> don't know if this changes anything. > > Not really, I should have said 'cgi' module as a whole rather than > specifically cgi.FieldStorage. Given that people might be using > cgi.parse_multipart in standard CGI, there would probably still be an > expectation that it worked for WSGI. We can't really say that you can > use cgi.FieldStorage but not cgi.parse_multipart. People will just > expect all the normal tools people would use for this to work.
Personally, I think parse_multipart should go away. It's not suitable for anything but toy usage. If people use it, and they expose their site to the world, arbitrary anonymous visitors can cause their Python's process size to grow to arbitrarily. I don't think any existing well-known framework uses it, for this very reason. If it can't go away, and there's a problem due to the non-parity between parse_multipart's use and FieldStorage's use, I suspect the right answer is to change cgi.parse_multipart to pass in a size value for readline too. I probably should have done that when I made the patch. :-( - C _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
