Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:50898 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 71928 invoked from network); 7 Dec 2010 12:49:02 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Dec 2010 12:49:02 -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:64459] helo=mail-qw0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 76/50-04382-D3D2EFC4 for ; Tue, 07 Dec 2010 07:49:02 -0500 Received: by qwj8 with SMTP id 8so9102615qwj.29 for ; Tue, 07 Dec 2010 04:48:59 -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=1DpD38YkjonXnnjze60S6vkxjbhGjz4jAk9Q5gmElgg=; b=SnhZkMZSehBASvOCKXu6t5t7JwBKofaVSMjRwTZP/oRsDx4+877O4QYRQd45ER1Ey1 bvp2FZPnj99fsOzvcMU3jhqK/7QxgGCXrT3X8yT+qHl4LxNU/jypEEHPi5i/zSM2HRjH 0sg4HpQBgjDv8qSTuEiTB3rdPlLT/Zq9nFQaI= 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=cJwFWlSg14DRe1DmsZAt5MrHmMj4Q1qGtHkCY8ATdXUpn2UzzbB6L5ewp7HoCibR9E qvUxyxxtaWgs3QwtAyWDToPAIHrmUddDlQFdIm5kFkPImDnTTOCahCeqE/SMZmYCZHVg HufllQXz+M5KWaB6eH/PiJkG2nId+ASx8IYCw= Received: by 10.229.228.76 with SMTP id jd12mr5540976qcb.291.1291726138549; Tue, 07 Dec 2010 04:48:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.100.130 with HTTP; Tue, 7 Dec 2010 04:48:38 -0800 (PST) Reply-To: RQuadling@googlemail.com In-Reply-To: References: Date: Tue, 7 Dec 2010 12:48:38 +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:42, John Mertic wrote: >> 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 > http://httpd.apache.org/docs/2.0/mod/core.html#files looks like it should. Now to find out how to do that for IIS. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY