Message3228
| 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:03 | admin | link | issue231249 messages |
| 2007年08月23日 13:53:03 | admin | create |
|