Skip Menu |

This queue is for tickets about the HTTP-Body CPAN distribution.

Report information
The Basics
Id: 84004
Status: new
Priority: 0/
Queue: HTTP-Body

Owner: Nobody in particular
Requestors: mods [...]

Bug Information
Severity: Important
Broken in: (no value)
Fixed in: (no value)

Subject: HTTP::Body::MultiPart still leaves temp files around.
Download (untitled) / with headers
text/plain 978b
The attempted fix to use cleanup(1) and DESTROY is flawed in that it looks for $self->{upload} items. But, those are not created until the full part has been read. So, if the connection is aborted (which is a common situation for uploads taking too long, for example) the temp file is never cleaned up. This could have significant impact over time for a production use. The solution is to let File::Temp do its job and let File::Temp unlink when the object goes out of scope. Then don't delete "fh" from the body part so it stays around until the upload object goes out of scope. This could break someone that is copying the filenname then then letting the upload go out of scope, but it's a temp file after all and it should not live long. And it's much better than risking filling up someone's /tmp. Misusing HTTP::Body and having a file vanish should show up with minimal testing. Running out of disk space is more likely to happen once in production.
Download (untitled) / with headers
text/plain 435b
I can supply a patch for this, but wanted a bit of discussion first. The problem is that the cleanup code in DESTROY only deletes files in the "upload" hash -- but those are only added when an upload part is complete. So, aborted uploads (the most common situation) will still leave temp files behind. We override handler() and create the temp file with UNLINK => 1. Is there a reason this was not done this way originally?

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to