Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:50895 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 67398 invoked from network); 7 Dec 2010 12:37:42 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Dec 2010 12:37:42 -0000 Authentication-Results: pb1.pair.com smtp.mail=rquadling@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=rquadling@gmail.com; sender-id=pass; domainkeys=bad Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.42 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: rquadling@gmail.com X-Host-Fingerprint: 209.85.216.42 mail-qw0-f42.google.com Received: from [209.85.216.42] ([209.85.216.42:46162] helo=mail-qw0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 68/F3-40992-59A2EFC4 for ; Tue, 07 Dec 2010 07:37:42 -0500 Received: by qwj8 with SMTP id 8so9090767qwj.29 for ; Tue, 07 Dec 2010 04:37:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:reply-to :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; bh=aHHRAz/vVuEn6bXcNG7YA68mh4VdNzJLoc8zZD1j9CA=; b=S6zPNa2IkBFykzN3nSEQ6HEjQGhRkQX7tmJxMB9FjpdvsqANz52OxQNqBc3EUXwDkn GHxEmdUgXfHB/dBnF4SSZZ610FJb6yXCK6WCNBCS7d0mEfaeBAveTkzd7BPjJW1jyo5N Uu8pM/dyGJqulfsI1DTicqr/c9bi8L8kKEqcw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; b=cqYvKwyp0njC9OyAQBMC2D4me8vvQhr8E96e3RzluH7pnpWkwy/50sstkrfoIguwJr +ZcrbONFwchPx+yeOJGQu8VpMxSTshZETmeRHTlBDDMXjj7t7jzoguYUp/ibgZRWE7dF qsPreyld6myd7HhfShHc9b9jgWs96dKKBvt7s= Received: by 10.229.227.12 with SMTP id iy12mr5669269qcb.101.1291725452028; Tue, 07 Dec 2010 04:37:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.100.130 with HTTP; Tue, 7 Dec 2010 04:37:11 -0800 (PST) Reply-To: RQuadling@googlemail.com In-Reply-To: References: Date: Tue, 7 Dec 2010 12:37:11 +0000 Message-ID: To: John Mertic Cc: 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: rquadling@gmail.com (Richard Quadling) 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