Ticket #546 (defect)
Opened 4 years ago
Last modified 4 years ago
[PATCH] concurrent file uploading limits, possible additional tracking features
Status: closed (wontfix)
| Reported by: | tweekgeek | Assigned to: | fumanchu |
|---|---|---|---|
| Priority: | normal | Milestone: | 3.0 |
| Component: | CherryPy code | Keywords: | uploads, cherrypy-extras |
| Cc: |
As discussed on the mailing list it would be nice to allow the configuration of cp to limit the number of concurrent file uploads, simply to avoid tying up all available threads.
A few other improvements to file uploads could be added as well... The filter I wrote for 2.2 (attached) offers a few additional features that aren't completely necessary for v3, but would be useful (upload status, minimum up speeds, etc). The explicit declaration of file-accepting functions seems like a must to me, though, simply to prevent sites that don't even accept files from becoming subject to some simply implemented dos.
Attachments
Change History
08/04/06 14:07:59: Modified by tweekgeek
- attachment uploadfilter.py added.
08/04/06 14:54:27: Modified by michele
Some times ago on the TG mailing list Bob Ippolito also suggested using a filter to stream the file during the upload.
08/19/06 08:14:22: Modified by michele
- summary changed from concurrent file uploading limits, possible additional tracking features to [PATCH] concurrent file uploading limits, possible additional tracking features.
08/27/06 01:21:22: Modified by lawouach
The idea is very nice but should it be included into core? Really I don't know. It might be interesting to have a cherrypy.extra project on the side of core that gathers those "very handy recipes" without polluting the core.
08/31/06 08:00:02: Modified by michele
I think at least the upload limit part should go into the core, the tracking feature could be added to a new tool?
09/02/06 04:55:00: Modified by michele
- keywords changed from uploads to uploads, cherrypy-extras.
Adding cherrypy-extras keywork, even I find them useful to have inside the core I think the tracking features *could* belong to such a package (fumanchu should decide).
09/02/06 19:41:42: Modified by fumanchu
- status changed from new to closed.
- resolution set to wontfix.
Closing as 'wontfix', because 1) as-is, it's more appropriate as a third-party tool, 2) the core would prefer each feature to be separated into a smaller Tool, and 3) much of it can be done using existing tools:
- upload_timeout: CP 3 has a new deadlock monitor in conjunction with request.timeout, with a hook users can put inside their own equivalent to ProgressFile?.
- upload_maxsize: duplicates max_request_body_size
- upload_minspeed: the only reason to inspect this is for the side-effect that the conn doesn't hang open too long, which can be solved better with request.timeout.
- upload_limit: if you really want to reserve some threads for uploads and some for "other", CP 3 allows you to start another HTTP server, which you could dedicate on its own port for that purpose. This might be useful as a standalone CP 3 Tool.
- explicit/declared: good idea, but is better done with an Allow header and the "405 Method Not Allowed" response. This functionality should be available orthogonally to an upload tool (and is, in CP 3's MethodDispatcher?).
The "eta" functionality is a nice thing to have, but should be developed independently.
Filter for 2.2