Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:81845 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 20699 invoked from network); 4 Feb 2015 23:43:29 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Feb 2015 23:43:29 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.45 as permitted sender) X-PHP-List-Original-Sender: smalyshev@gmail.com X-Host-Fingerprint: 209.85.220.45 mail-pa0-f45.google.com Received: from [209.85.220.45] ([209.85.220.45:44634] helo=mail-pa0-f45.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A5/6E-40930-F9EA2D45 for ; Wed, 04 Feb 2015 18:43:28 -0500 Received: by mail-pa0-f45.google.com with SMTP id et14so5933358pad.4 for ; Wed, 04 Feb 2015 15:43:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=zqH1ewbIf2zpBZ+Z5QAeKblrexPEYPshYBgp+Sc0fPA=; b=esCvyqSxKFUPg6e0qqJnPNV6Ns4tPLlPABRGr2ELzidveSkV14wza7quH64rO6xJAy D6cBfZp7fWa4Vw0U8QZTYoyOgFzxmNF2wNY1EO8/EuT3o5X9mKhwZ+8fbYAN9OAEzklM YGNgJQHYfS0+sO/+QMJj3x2YSougW58mjk4ku2Wnu3fIVZBR+oDlDcWjOr6RZkajmrQj vgPWzCZbCJgrlXqL/bwNwklU80gkVsxcJZcP/rfSDtSoT44mBuyez/5/ibJrKX/S9hGr ISBhHNyQq32akfMONMLGcaDQkkT13FRYKP7SAVkaBq23esEDMpqUlmUCwqalsBuPQcJU DNDg== X-Received: by 10.68.195.234 with SMTP id ih10mr1268797pbc.66.1423093405366; Wed, 04 Feb 2015 15:43:25 -0800 (PST) Received: from Stas-Air.local (108-66-6-48.lightspeed.sntcca.sbcglobal.net. [108.66.6.48]) by mx.google.com with ESMTPSA id gj9sm3116834pbc.32.2015.02.04.15.43.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Feb 2015 15:43:24 -0800 (PST) Message-ID: <54D2AE91.8090800@gmail.com> Date: Wed, 04 Feb 2015 15:43:13 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Michael Wallner , PHP Internals References: <54D217E7.8030407@php.net> In-Reply-To: <54D217E7.8030407@php.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http From: smalyshev@gmail.com (Stanislav Malyshev) Hi! > Points explicitely marked for discussion in the RFC itself: > > * pecl/propro > Proxies for properties representing state in internal C structs > https://wiki.php.net/rfc/pecl_http#peclpropro > > * pecl/raphf > (Persistent) handle management within objects instead of resources > https://wiki.php.net/rfc/pecl_http#peclraphf > Also, take special note of the INI setting: > https://wiki.php.net/rfc/pecl_http#raphf_ini_setting I'm still not sure why we need these two, to be frank. E.g., for the former I can kind of get it, though I don't see any use-case that really requires going to such lengths, for the latter I'm not even sure what the case for that is - i.e., why exactly would one need persistent HTTP connections surviving the request? > > * POST parsing disregarding request method, solely based on content-type > https://wiki.php.net/rfc/pecl_http#rinit I'm not sure what exactly happens there. Is _POST in the RFC code populated for every kind of request automatically? That may be unexpected, though the ability to parse incoming data as POST regardless of method may be useful. But it'd help to have a description of what exactly changes. -- Stas Malyshev smalyshev@gmail.com