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
Unknown Object (File)
Fri, Apr 19, 2:42 AM
Unknown Object (File)
Wed, Apr 3, 8:19 AM
Unknown Object (File)
Sun, Mar 31, 12:30 PM
Unknown Object (File)
Sun, Mar 31, 5:51 AM
Unknown Object (File)
Feb 13 2024, 10:45 AM
Unknown Object (File)
Jan 16 2024, 3:01 AM
Unknown Object (File)
Jan 4 2024, 10:37 AM
Unknown Object (File)
Jan 2 2024, 4:38 PM
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.