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. 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 > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
