Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:50897 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 70219 invoked from network); 7 Dec 2010 12:42:11 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Dec 2010 12:42:11 -0000 Authentication-Results: pb1.pair.com header.from=jmertic@gmail.com; sender-id=pass; domainkeys=bad Authentication-Results: pb1.pair.com smtp.mail=jmertic@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: jmertic@gmail.com X-Host-Fingerprint: 74.125.82.54 mail-ww0-f54.google.com Received: from [74.125.82.54] ([74.125.82.54:48482] helo=mail-ww0-f54.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C3/00-04382-2AB2EFC4 for ; Tue, 07 Dec 2010 07:42:10 -0500 Received: by wwb31 with SMTP id 31so12686412wwb.11 for ; Tue, 07 Dec 2010 04:42:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=Vi+u5cvTyQggv2QPdvkRQCjhyCMudKrrrp6BcH0mt8E=; b=VenfKNGe0osdOzS+LydF5EBgMXTqqBX5bnxZQJ5Mp/8d3kvWFR/OHH7Y8jscJvVjjE b00qef+FL6Kcp2VKtjtmdHGrLbN4eUTVi0T0GXosjWFbcp3NP1Pb2cdUw5IDQzk4Nzj7 +1GvHwELAI/EWSwyyMHB3LBvkr+1C8Ee1ooQY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=juXdMXC7cRaCNYyNoHBbOHv+kQuCCJ/+QVfG8bzaPlbnd8j9qvL5k41cfFNhEAzfgY ufQPC6P8Nwdl9vFDPNS/d+iVspB1ZmZ4viSaLESwvNeU/JvSb82M7V/9ZODS+jHmGOsN 09ZjIizHYV3Z3LNK9XaXYf0osgejKFrPNqpbE= MIME-Version: 1.0 Received: by 10.227.128.84 with SMTP id j20mr7191747wbs.206.1291725727310; Tue, 07 Dec 2010 04:42:07 -0800 (PST) Sender: jmertic@gmail.com Received: by 10.227.152.210 with HTTP; Tue, 7 Dec 2010 04:42:06 -0800 (PST) In-Reply-To: References: Date: Tue, 7 Dec 2010 07:42:06 -0500 X-Google-Sender-Auth: nVD7BUMA5xzIOmwW3l4blLIEb3M Message-ID: To: Gustavo Lopes , "internals@lists.php.net" Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] [PATCH] Add option to disable POST data processing From: jmertic@php.net (John Mertic) > On Tue, Dec 7, 2010 at 7:37 AM, Richard Quadling wrote: >> On 7 December 2010 12:11, John Mertic wrote: >>> On Tue, Dec 7, 2010 at 6:40 AM, Richard Quadling wrote: >>>> On 7 December 2010 07:08, Gustavo Lopes 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 >>> jmertic@gmail.com | http://jmertic.wordpress.com >>> >> >> Can you set an ini option via .htaccess for a single script? >> >> If the script has to reside in its own directory then that makes >> sense, but I don't know how to set an ini option for a single script. >> >> -- >> Richard Quadling >> Twitter : EE : Zend >> @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY >> Wouldn't something like this work? php_value disable_post_data_processing On John Mertic jmertic@gmail.com | http://jmertic.wordpress.com