Uploads over 4.5 MB: sending files straight to storage

The report said: after deleting videos, uploading the same names again fails. It sounded like a naming clash. It was neither deleting nor names. Any file over about 4.5 MB could not be uploaded to genvi at all, and our own code never got the chance to say so. This is how we moved big uploads, over 4.5 MB, straight to storage.

You saw two words and no reason. A 7.6 MB video and a 22 MB video both failed. The link to deleting looked real because people often delete things to free space, then retry the big file.

We tested the live site instead of guessing. A 6 MB upload was rejected before it reached our code. A tiny 1 KB upload reached our code and got a normal answer. So the host that runs our site refuses any upload over roughly 4.5 MB before our server even starts. None of our own limits ever applied. That hidden ceiling quietly capped every upload in the app, whatever the app said its limit was.

The host's refusal comes back as a web page, not the kind of message our app knows how to read. The browser tried to read it, failed, and fell back to "Upload failed". Two problems stacked up: a limit we could not see, and an error path that assumed every failure came from us.

Files now go straight to our storage service, in three steps.

We already used this idea for our own admin files. We had just never used it for your files. The upload bar now shows real progress, because it tracks how much of the file has been sent.

This is the part that matters most. Before, our server saw the file, so it could check it. Now the file goes around our server. A check that is missing in one place is missing completely. So we made four decisions.

One set of rules. The allowed file types, the size limit and how to tell a file's type live in one place, and both steps use it. Browsers often report an unknown type for some files, such as 3D models and certain videos. So the file name decides when the reported type is no help.

Check before the ticket. We only give a ticket after the type, size and your storage space pass. A test confirms that the checks come before the ticket is made.

We choose the spot. The place a file is saved is built by our server from your account and a new file number. If a caller could pick the place, they could write into anyone's folder.

Read it back, never believe it. When the app says it is done, we measure the file size ourselves from storage. We do not trust the number from your browser. Your storage total depends on that size, so a made-up size could slip past your limit forever. We also run the file rules again on what actually arrived. We refuse a file outside your folder, refuse a file that is not there, and delete the file if we cannot record it.

The app now shows our server's message when there is one, so a real limit reads as a real limit.

We added 21 new checks with this change. They confirm that the safety rules did not go missing in the move. A program file is refused, a file that is too large is refused, and the 22 MB video from the report is allowed. They also confirm that both steps use the same rules, that checks come before the ticket, and that our server builds the file's spot.

We also tried it live. A 22 MB ticket was issued and a program file was refused. A 6 MB file went through all three steps, was recorded at exactly 6291456 bytes, appeared in the file list and was deleted cleanly.

That change fixed only the place where the problem was reported. Some other upload spots still used the old upload path and kept the 4.5 MB limit until they were moved too. We said so openly rather than pretending it was finished. If a limit lives in the host in front of your code, the first sign of it is an error you never wrote.