[Dancer-users] Uploaded files: what is their life-cycle?

[Daniel Pittman]

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 at rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cleanup.patch
Type: text/x-diff
Size: 358 bytes
Desc: not available
URL: <http://www.backup-manager.org/pipermail/dancer-users/attachments/20100616/f63b401e/attachment.patch>