On Tue, Dec 7, 2010 at 8:08 AM, 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 > Did we agree on something about this improvement/patch? as I said, I like the idea, but if we cannot agree on the details(how to control that which script needs this), could we somehow at least make it possible to read the raw post through php://input for "multipart/form-data" requests? currently just no way to read the raw data for those requests which sucks big time. Tyrael
