Page MenuHomePhabricator

Stream "multipart/form-data" file uploads to disk
ClosedPublic

Authored by epriestley on Oct 10 2017, 10:16 PM.
Tags
None
Referenced Files
F15518801: D18701.id44893.diff
Sat, Apr 19, 5:00 PM
F15463930: D18701.id44900.diff
Wed, Apr 2, 4:38 AM
F15441709: D18701.diff
Wed, Mar 26, 7:30 PM
F15438534: D18701.id44893.diff
Wed, Mar 26, 1:19 AM
F15434815: D18701.id44900.diff
Tue, Mar 25, 5:37 AM
F15432527: D18701.id.diff
Mar 24 2025, 6:27 PM
F15432377: D18701.id.diff
Mar 24 2025, 5:51 PM
F15425419: D18701.diff
Mar 23 2025, 4:38 AM
Subscribers
None

Details

Summary

Depends on D18700. Ref T13008. Adds support for sending file uploads to disk, similar to the buitin PHP mechanism, and a compatibility layer for building $_FILES.

Test Plan

See next diff; uploaded files using a vanilla file upload with enable_post_data_reading off.

Diff Detail

Repository
rPHU libphutil
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Do we currently write uploads to disk temporarily? I guess rate limiting will prevent this, but I'm worried this opens ourselves up to a DoS by filling disks (especially if there's a problem with S3 or whatever persistence layer that could cause these files to accumulate).

This revision is now accepted and ready to land.Oct 11 2017, 8:34 PM

Yeah, the default behavior for PHP is to write multipart/form-data uploads to tempfiles on disk.

We could theoretically stream these directly into S3, but that's another good chunk of work.

If we ran into issues with this, we could attach dedicated volumes to web as a buffer, or put more rate limiting in place, or whatever else, but I think the risk of this is small, and it's fairly minor if /tmp fills up on web nodes. (See also T12857.)

This revision was automatically updated to reflect the committed changes.