On 2010-12-16, Pierre Joye <pierre....@gmail.com> wrote: > There are a lot of values to disable POST completely. That's also why > thinking the option you are proposing while keeping in mind the whole > picture makes sense. > > There are different existing modes and one or two new modes (to be > introduced, like disabling POST). Having a clean way to choose which > mode should be used for a request makes sense and will improve the > user experience. Right now and as shown the confusing discussions on > IRC (or partially here) shows that the current situation is a mess. > > Again, I'm not saying that the idea behind this patch is bad, only > that there is a better way to do it while being less confusing and > making the whole thing cleaner to define.
Seriously, disabling POST via a php.ini setting is considered a "sensible" option? Has nobody ever developed a RESTful application? 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. > 2010/12/16 Gustavo Lopes <glo...@nebm.ist.utl.pt>: >> On Thu, 16 Dec 2010 12:47:43 -0000, Pierre Joye <pierre....@gmail.com> >> wrote: >> >> As I said in IRC, I see no value in having an option that disables >> accessing POST data completely (i.e. the behavior of >> enable_post_data_reading=Off + disallowing reading it through >> php://input). >> >> With enable_post_data_reading=Off, the only way to access the data is >> through php://input; if the script uses the wrapper to read the data is >> because it presumably needs, or expects, such data. If the script doesn't >> need it, it won't read php://input. Activating a putative option that >> completely disabled reading POST data would break the first script and >> would have no effect on the second. And it's not like there would be >> performance benefits from introducing such as option. >> >> More importantly, the enable_post_data_reading is to allow efficient >> handling of POST data and access to raw POST data with multipart requests. >> Adding an option that disables accessing POST data completely would not >> help. >> >>> On Thu, Dec 16, 2010 at 1:42 PM, Ferenc Kovacs <i...@tyrael.hu> wrote: >>> >>>> So currently we didn't talk about security measures, but performance >> >>>> gains: >>>> If somebody wants to write a script, which handles big file uploads, >> but >>>> only writes it to somewhere (to file, or another stream), then >>>> currently you have to allocate the memory for the post data twice(see >>>> the first email), which is very inefficient if you don't need the >>>> $_POST at all. >>> >>> yes, but that's something very confusing right now, the naming and the >>> other ways to access POST data. The goal of this idea is a good thing >>> to do, but the naming and its implementation are confusing (processing >>> vs reading vs used at all). >>> >> >> I don't thinks it's that confusing. This new option just prevents PHP from >> doing any automatic reading and processing of the POST data, leaving it >> entirely on the hands of the programmer to that, if he wishes, through >> php://input. >> >> What is confusing is the different behavior of PHP with >> $HTTP_RAW_POST_DATA and the influence always_populate_post_data and the >> different handling of urlencoded vs multipart vs other content-type POST >> requests vs non-POST requests with a request body. >> >> -- >> Gustavo Lopes >> > > > -- 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
