• (nodebb)

    I guess that comparing the size against 20971520 was too hard. Or maybe 20*1024*1024.

  • Bittle Tobby Lables (unregistered)

    Critical bug then.

  • Brian Boorman (google)

    Poorly written first paragraph. Did they have files larger than 20MB that they needed to upload (and this needed to fix code) or were they finding that users were uploading files larger than 20MB when they shouldn't be able to? The text is ambiguous. I read it as the former and was confused until I figured out from the code that it was the latter.

  • (nodebb)

    Worse yet: $uploadedFile looks like "file which has already been uploaded". Why do you upload too large a file frist, only to discard it afterwards? If it gets discarded at all - perhaps more likely spamming some temp directory which may or may not occasionally get cleaned.

  • SG (unregistered) in reply to BernieTheBernie

    How else would you validate the size of a file being uploaded through a web app? Surely you're not going to trust what the client code says?

  • Stella (unregistered)

    That's mebibytes, not marketing bytes. Which means the effective upload limit was slightly over 19 marketing bytes, not 19.5 MiB.

  • (nodebb)

    Maybe he was afraid that multiplying 2010241024 produces a large number and it would overheat the CPU?

  • Malte (unregistered)

    The sort of error I play code-golf on. I believe it's one byte, a dot behind the first 20, so everything becomes floating point arithmetic.

  • Hanzito (unregistered) in reply to BernieTheBernie

    The frontend might also check the file size, and this is just there to be sure nobody uses curl to circumvent the limit. Or something like that.

  • (nodebb)

    I don't see how using floor would solve the problem... If someone uploads a file that is slightly larger that 20MB (say, 20972000 bytes), floor ($uploadedFile->getSize() / 1024 / 1024) will be 20, which is not > 20, so it will accept the file even though it's too large. There's no need for rounding or truncating here, just compare the size to 20 * 1024 * 1024.

  • m (unregistered)

    I would try to ensure, that it accepts any file that is shown with size "20 MB" in any file manager the users can be expected to use. Life's too short for support calls!

    So, floor/truncate does not solve the problem they believe they have, but it's still a good thing to do

  • Daniel Orner (github) in reply to BernieTheBernie

    In order to check the file size on the server, the client first has to send the file to it. "Uploaded" here means "uploaded by the client to the server", not "uploaded from the server to wherever it has to go for permanent storage".

    There are ways to check the file size on the client, but that would mean front-end code, not back-end code. Which isn't bad, but isn't sufficient if you want to put a hard limit on this file, since front-end code can always theoretically be messed with by someone curious, determined, and/or malicious.

  • Michael (unregistered) in reply to tom103

    Well, it's floor combined with changing the > 20 to >= 20. or > 19. Or using ceil() instead. Or not rounding at all, since php will cast the (int) 20 to float (20.0) on its own since this isn't Java. or the many many other ways this could work.. It's actually really hard to make this NOT work in PHP, but they managed to find a way...

  • Barry Margolin (github)

    Unless this limit is only for this specific application, you can just set the php.ini parameter upload_max_filesize and it will be checked automaticaly.

  • Abigail (unregistered)

    Using floor instead of round makes it worse, doesn't it? With round, it throws an error if the file is 20.5 Mb or larger, with floor it will accept any file not exceeding 21 Mb.

    But, surely, PHP can compare a float with an integer, can't it? Leaving off the round would be best. Or use ceil if you really insist to compare integers.

  • Loren Pechtel (unregistered)

    So what? They used the 2^20 definition rather than 10^6. Not a WTF to me.

  • Yikes (unregistered)

    It seems like an appropriate solution would be to have the web service that's assembling upload chunks error out once the programmed limit has been exceeded for that upload. If you didn't care about bandwidth, then the service could continue to receive chunks without actually writing them to disk and once a higher threshold has been met, it could label the sender as potentially hostile.

  • DJ Dizzy Spudplucker (unregistered) in reply to Stella

    "Marketing Bytes"! Learned a new unit today. You're not wrong....

  • Дмитрий (unregistered) in reply to Yikes

    HTTP 1.1 allows the server to respond before it completely receives the request. So the server could send an error page right after checking Content-Length in the request. However, it is impossible in PHP because PHP won't run until the request is complete. So the real WTF here is PHP.

  • (nodebb)

    I'm utterly unable to understand what role rounding or truncation can possibly play here.

  • (nodebb) in reply to Malte

    @Malte

    I believe it's one byte, a dot behind the first 20, so everything becomes floating point arithmetic.

    It's already floating point - PHP doesn't do integer division like C does:

    $ php -r "echo 4/5;"
0.8
$
  • smf (unregistered)

    How exactly is this a WTF?

    if (round($uploadedFile->getSize() / 1024 / 1024) > 20) { [ ... throw some error message ] }

    I'd want to see the original change request.

  • Antoine (unregistered)

    If only PHP had a built-in settings to limit the size of uploaded files...

  • (nodebb) in reply to smf

    How exactly is this a WTF?

    Because any file of size less than 20.5 Mb* will pass validation. A file can be nearly 512 kb too big and still get uploaded. There's also the fact that they didn't haver to do the divisions and the round/ceiling at all if they had just compared the size in bytes with 2 * 1024 * 1024

    • all units are of the "two to the power of" variety.
  • Ollie Jones (unregistered)

    Hmm. The php engine does this upload_max_filesize checking for you. https://www.php.net/manual/en/ini.core.php#ini.upload-max-filesize

    Here, the developer reinvented the flat tire.

  • luis lit (unregistered)

    Weed market420 is an established source for buying weed online in USA & Canada. We are a reputable organization with a steady base of customers growing rapidly. We realize it’s not easy searching online for the safest, quickest and most reliable source to buy cannabis online which is why we survey thousands of customers to provide reviews online so you can reassure yourselves that we are the real dealers. https://weedmarket420.us/product/buy-chocolate-mushrooms/ https://weedmarket420.us/product/dark-chocolate-raspberry/ https://weedmarket420.us/product/just-a-tickle-shroom-bars/ https://weedmarket420.us/product/magic-boom-bars/ https://weedmarket420.us/product/trippy-flip-milk-chocolate-bar/ https://weedmarket420.us/product/wonder-bar-mushroom-bar/ https://weedmarket420.us/product/just-a-tickle-shroom-bars/ https://weedmarket420.us/product/goal-coast-clear-for-sale/ https://weedmarket420.us/product/order-cheap-carts-online-usa/ https://weedmarket420.us/product/buy-gold-coast-clear-online/ https://weedmarket420.us/product/buy-gold-coast-carts-online/ https://weedmarket420.us/product/cocaine-for-sale-online/ https://weedmarket420.us/product/peruvian-89-pure-fishscale-cocaine/ https://weedmarket420.us/product/buy-peruvian-fishscale-cocaine-online/ https://weedmarket420.us/product/colombian-cocaine/ https://weedmarket420.us/product/cracks-cocaine/ https://weedmarket420.us/product/buy-peruvian-cocaine-92-pure/ https://weedmarket420.us/product/buy-pure-powder-cocaine-online/

  • Haaris grey (unregistered)

    Searching for the best weed delivery service near you! Look no further! Weed market420 Delivery is one of the most trusted, professional and top-quality weed delivery services in California. Weedmarket420 Express delivers legal, dependable, quality medicinal and recreational cannabis that caters to your desires at a competitive price with FAST and friendly service. See this page. https://weedmarket420.us/

  • markm (unregistered) in reply to Loren Pechtel

    "So what? They used the 2^20 definition rather than 10^6." No, like several other posters, you missed the WTF entirely. Due to the divisions and the resulting rounding errors, it accepts files larger than 2^20 assuming the arithmetic is done in a large integer data type. If the /20 is done last rather than first, it will accept files over half a meg too large (a 2.5% error); if it is done in left to right order, the accumulated rounding error is smaller, but still a problem if later processing checks the size again, corrrectly. Floating point calculations would be off slightly, as always, but the error would be small and may be plus or minus.

    But the true WTF is dividing the file size at all rather than computing the maximum file size and comparing that to the file size. If that isn't like fingernails scratching a chalkboard to you, you need to learn more math or more about how computers do it.

Leave a comment on “Around 20 Meg”

Log In or post as a guest

Replying to comment #572180:

Log Out

« Return to Article