This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author richard
Recipients
Date 2001-06-08.05:19:47
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Logged In: YES 
user_id=6405

I've just encountered this bug myself on Mac OS X. The 
default number for "ulimit -n" is 256, so you can imagine 
that it's a little worrying that I ran out :)

As has been discussed, the multipart/form-data sumission 
sends a sub-part for every form name=value pair. I ran 
into the bug in cgi.py because I have a select list with 
>256 options - which I selected all entries in. This tips 
me over the 256 open file limit.

I have two half-baked alternative suggestions for a 
solution:
 1. use a single tempfile, opened when the multipart 
parsing is started. That tempfile may then be passed to 
the child FieldStorage instances and used by the 
parse_single calls. The child instances just keep track of 
their index and length in the tempfile.
 2. use StringIO for parts of type "text/plain" and use a 
tempfile for all the rest. This has the problem that 
someone could cut-paste a core image into a text field 
though.

I might have a crack at a patch for approach #1 this 
weekend...
History
Date User Action Args
2007-08-23 13:53:03adminlinkissue231249 messages
2007-08-23 13:53:03admincreate