On 2010-12-16, Pierre Joye <pierre....@gmail.com> wrote: > On Thu, Dec 16, 2010 at 3:18 PM, Matthew Weier O'Phinney ><weierophin...@php.net> wrote: >> On 2010-12-16, Pierre Joye <pierre....@gmail.com> wrote: > > The only way I can see such an action being "sensible" is if it's also > > runtime configurable (i.e., via ini_set()) - otherwise I foresee a ton > > of issues between security-paranoid sysadmins and developers when code > > is pushed to production and simply stops working... > > > > I understand the rationale behind Pierre's assertion, but it's > > incredibly short-sighted when you consider a full application, where > > some actions need to accept raw POST/PUT data (man, would I love a $_PUT > > superglobal...), others need to accept file uploads, and most others > > need neither. > > I never said it should be a php.ini option, or only a php.ini option. > But having 300 ways to do the same things, or to change options is > bad. You should also keep in mind that even if it is a php.ini option, > it should obviously be INI_PER_DIR and not system wild (that's what > servers options exist, or better appropriate there if one wants to > disable POST permanently and for all requests/URLs).
INI_PER_DIR doesn't work for, I would argue, the majority of modern PHP applications. If you look at most frameworks, CMS solutions, or standalone apps such as WordPress, there's a single script acting as the gateway to all functionality (basically, a front controller). Making the setting INI_PER_DIR means that you have to move any functionality that may potentially require access to raw POST/PUT data into separate scripts and/or directories -- which splits functionality away from the front controller and makes maintenance much more difficult. > All in all, I don't think adding a set of new ini settings for very > specific and disputable features is not something good to do. If we > need something to process file uploads more efficiently, then let do > it in a good way (no, processing php://input manually is not what I > can consider as a good way :). I'm not talking about processing file uploads; I'm talking about normal handling of raw POST/PUT body content -- something that's very, very common when dealing with RESTful or RPC APIs, where the format isn't normal URL encoding, but instead something like XML or JSON. I'm all for better, more efficient processing of file uploads -- but not at the expense of being able to build good APIs. -- Matthew Weier O'Phinney Project Lead | matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
