> We spend a lot of time to increase limits for uploads file in PHP. For a lot of time, I assume you are using a web host that does not allow modification to INI file directly or using INI functions, and you have to contact your host provider for that change. Otherwise, it is not that difficult to apply that change. Plus, this question would have been answered in a php forum, like phpearth. > I'm not against increasing the sizes, but 50MB might be too much. It is possible on userland as well as configuration level. I don't feel like it is worth doing. It will break some websites. Most of the projects go with default options of upload; thus, doing so will make issues for such projects. > By the Way... This needs an RFC right? This change should be made with an rfc. Because it will impact a majority of projects, and usually devs doant have to have that huge limit. Plus, there are razed further concerns that
On 9/10/22, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > 2022年9月10日(土) 23:23 David Gebler <davidgeb...@gmail.com>: > >> On Sat, Sep 10, 2022 at 3:05 PM juan carlos morales < >> dev.juan.mora...@gmail.com> wrote: >> >>> I also agree that increasing the size to something bigger than 8M >>> might not be a good idea; I can imagine that a value bigger than 8M >>> (like 50M) will cause an impact in hosting platforms specially, which >>> will be forced to always change the php's default values to a lower >>> one, because of potential DoS Attacks. >>> >>> Default settings should have a reasonable level of security in mind. >>> >> >> Do these settings actually have any impact in respect of DoS attacks? As >> far as I'm aware, neither post_max_size nor upload_max_filesize do >> anything >> to prevent or terminate processes where the client sends data exceeding >> these limits, that's something you should handle in your webserver. >> > > For example, password hash DoS attack was made possible because PHP allows > 8MB post data. > > https://www.acunetix.com/vulnerabilities/web/long-password-denial-of-service/ > > IIRC, Drupal has a security release for this. > > Regards, > > -- > Yasuo Ohgaki > yohg...@ohgaki.net > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
