Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:51051 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 46507 invoked from network); 16 Dec 2010 14:18:08 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Dec 2010 14:18:08 -0000 X-Host-Fingerprint: 65.19.76.48 unknown Date: Thu, 16 Dec 2010 09:18:07 -0500 Received: from [65.19.76.48] ([65.19.76.48:3839] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id EF/71-36789-F9F1A0D4 for ; Thu, 16 Dec 2010 09:18:07 -0500 Message-ID: To: internals@lists.php.net References: <6b2ba5e56d64910c49bb431ba1e36e17@nebm.ist.utl.pt> User-Agent: slrn/pre1.0.0-18 (Linux) X-Posted-By: 65.19.76.48 Subject: Re: [PHP-DEV] [PATCH] Add option to disable POST data processing From: weierophinney@php.net (Matthew Weier O'Phinney) On 2010-12-16, Pierre Joye 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 : >> On Thu, 16 Dec 2010 12:47:43 -0000, Pierre Joye >> 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 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 | matthew@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc