You're right, that would work, and it's how each chunk is done. The problem in both cases is that we waste time that we don't need to by writing the entire body to disk and then reading it after we have received the entirety of it. What we want is more like an abstract ring buffer where we are consuming bytes from one end of the buffer as the client sends bytes into the other end. That pipelining process would improve response times in both the chunked and the non-chunked case, by making the processing of data happen in parallel with the sending of data, so I think we should figure out how to do it.

In the chunked case, the user experience is slightly hindered by this limitation; after each chunk, you will notice a short pause before the next chunk is sent if you upload via the browser.  That pause is short enough that it doesn't really detriment the user experience too badly; we never have to process more than 64MB, so the duration of that pause is basically fixed, and pretty short. But if we upload, say, a 10GB file, the uploader would appear to just hang at the end for quite a while, and users would wonder what was going on. So, I think if we want to support single-shot uploading of any sized file, we should take the time to investigate how to expose the request body as a blocking, file-like IO stream and start running our request processing code as soon as we have the first bytes of the body. If I were doing that, the first thing I would try would be overriding the [make_file](http://cherrypy.readthedocs.org/en/latest/refman/_cpreqbody.html#cherrypy._cpreqbody.Entity.make_file) method of `_cpreqbody.Entity`.

That, or posting the question to stackoverflow, someone might have already solved this. :smile: