On Tue, Dec 7, 2010 at 6:40 AM, Richard Quadling <rquadl...@gmail.com> wrote: > On 7 December 2010 07:08, Gustavo Lopes <glo...@nebm.ist.utl.pt> wrote: >> The very simple attached patch adds an option to disable POST data >> processing, which implies the data can only be read in a stream fashion >> through php://input. >> >> As far as I know, PHP offers no way to inhibit processing RFC 1867 data and >> one has to use very hacky means to accomplish that. This is often required >> (or at least convenient) in order to, e.g., proxy requests or handle file >> uploads in memory. >> >> For other types of requests, the default processing of POST data may also be >> a problem. Take a non-application/x-www-form-urlencoded POST requests (say, >> some kind of RPC with a big XML payload) -- PHP is very memory inefficient >> as it will hold the whole POST data into memory and duplicate it twice (from >> SG(request_info).post_data to $HTTP_RAW_POST_DATA -- even if >> always_populate_raw_post_data=0 -- and SG(request_info).raw_post_data). >> >> This introduces a new ini setting, disable_post_data_processing, but it's a >> benign one. No incompatibilities between setups will arise because no one >> will enable it globally (it would be insane), only selectively to the >> scripts that require it. The reason for an ini setting is that it must be >> set early in the request life. >> >> Thoughts? >> >> -- >> Gustavo Lopes >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> > > As I understand things, the super globals are already populated by the > time the script starts execution. > > So, ini_set() will have no impact. > > Can you set an ini option for a single script via some other method? >
Maybe thru an .htaccess file? That should work. Otherwise, +1 for the patch from me. John Mertic jmer...@gmail.com | http://jmertic.wordpress.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
