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? -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
