G'day. I have been looking at the life of uploaded files in Dancer, since I need to perform a multi-stage interaction with my users while importing data from an Excel spreadsheet.[1] Anyway, as far as I can tell the default Dancer instance with 'load_app foo; start;' never deletes an uploaded temporary file. They just like on disk forever. So, I wondered: what is the life-cycle of them? Who should be deleting these files: - the underlying Plack (or internal) application server? - the HTTP::Body instance used by the Dancer core? - the Dancer core? - my application? My concern here is that none of them actually /do/ take responsibility for that, so right now anyone can fill the temporary space on my application server by sending requests to Dancer with files — ouch. FWIW, my personal preference would be that the Dancer core magically made this work, by ensuring that the files got deleted at the end of the request. Given that you can't robustly rely on storage within a single application server under Dancer[2], this makes the most sense — anyone who cares about that content will have arranged for it to persist during the request. Attached is the obvious, trivial, one-line patch that implements that, by telling the HTTP::Body instance to delete temporary files when destroyed. Daniel Footnotes: [1] Don't ask. It isn't really a choice. [2] ...because anyone could attach you to, say, a FastCGI Plack instance that forks multiple children, and you wouldn't even know until your application broke horribly. -- ✣ Daniel Pittman ✉ daniel@rimspace.net ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons