Page MenuHomePhabricator

Uploaded file size calculations to compare with upload quota
Open, LowPublicFeature


I think currently the servers demand to receive the complete file before verifying its size.

It would be better if it only received the portion set by the upload quota. In other words if the user is uploading a 500MB file, and the quota is 5MB. The upload should be canceled the second the file exceeds 5MB rather than waiting for the entire 500MB file.

This can also be exploited maliciously.

Version: unspecified
Severity: enhancement



Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 9:49 PM
bzimport set Reference to bz10976.
bzimport added a subscriber: Unknown Object (MLST).

I'm pretty sure this would require special support from PHP to abort the connection early; not sure if that's present.

robchur wrote:

(In reply to comment #0)

This can also be exploited maliciously.

I don't see how; please send details to

Email was sent to

Summary is roughly 'if you upload a lot of stuff, the servers' drives may fill up'.

Well, yeah. That's really a pretty general issue, since we keep all the submitted data even if it's deleted. ;)

The only operational issue specific to this would be:

  1. If you upload a file much much larger than the file upload limit,
    • then -
  1. It may fill up the victim web server's disk during the process.

That's an issue of how PHP handles its upload limit. Uploaded file data is saved to temporary files, thus usually in a /tmp directory, and discarded at the end of the request. The question is, if your upload is _bigger_ than the file size limit, does it discard the file *at the point where the limit is reached* or *after saving the entire file*.

I would expect that it discards the file at the point where the limit is reached, but we'd have to check... Ok, my quick peek at PHP's rfc1867.c which implements HTTP file upload handling looks like it deletes the temporary file when the upload is canceled, which is the safest course.

Filling up servers' /tmp areas could have some DoS consequences, but that's about the limit of it even if there was a problem. To perform the attack you'd have to upload a large number of files _under_ the size limit, and try to keep them there as long as possible. On Wikimedia's own configuration you'd also have to do enough of these to keep several hundred separate web servers *all* full. An annoyance at best, and hardly worth it.

Any improvements in handling behavior may have to be upstream (eg, better error reporting), assuming there's even a good way of handling it. You'd have to cut off the HTTP connection, I guess, so I'm not sure how you'd report the error cleanly.

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:01 AM
Aklapper removed a subscriber: wikibugs-l-list.