Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78528
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.27 cause and error)
Message-ID: <5453DC39.8060501@garfieldtech.com>
Date: Fri, 31 Oct 2014 14:00:09 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAL+t6cGt8B+X4ptWbyo6zm_xoyBOJC4QeiH6DjCxHX11CPWm_g@mail.gmail.com>	<5452B87B.5040009@garfieldtech.com>	<CAL+t6cHqQL-TaurfG887qxeyeVZPCxQcnY_BrtD-oHCS196HQw@mail.gmail.com>	<0B797CE3-7AFA-4330-9A98-D3CAFC6D6072@ajf.me>	<CAL+t6cGanxv3dJONcECupw6Cfzup4s6At6tEcK_=Qagn67RNjw@mail.gmail.com>	<5453B114.6050400@gmail.com>	<CAL+t6cFCToJJGiCb8JhNe9oQws5UuBdKw+ot3rjUBQQr=7=Bxw@mail.gmail.com>	<5453C250.8090803@gmail.com>	<CAL+t6cEH7PPMu2G=e4NQau-iOznkG31-d187EMCDY0LFeew68g@mail.gmail.com>	<CABRjmp-b1jGD1SBTxmnJFLKi++WbL4TBggijN+VfSjRjPMJYPQ@mail.gmail.com>	<CAL+t6cF7t7shs78xSiBfGxZSCqh5zcU-B_WWjK5J9ebiB=PTQA@mail.gmail.com>	<5453D6D5.2070705@garfieldtech.com> <CAL+t6cEyLFqQ9cRW3uiE-pRMsMEyOywAhWWDtg5zFFL-U2mogg@mail.gmail.com>
In-Reply-To: <CAL+t6cEyLFqQ9cRW3uiE-pRMsMEyOywAhWWDtg5zFFL-U2mogg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: larry@garfieldtech.com (Larry Garfield)

On 10/31/14, 1:52 PM, Sherif Ramadan wrote:
> So for the purposes of this discussion and in an effort to remain on-topic
> and productive, let's keep all of the FIG/PSR and other third party efforts
> out of the discussion unless it is intended to improve/help this particular
> RFC. Please keep in mind that this is a PHP internals discussion and not a
> FIG/PSR discussion. This RFC is about core PHP and I really don't care how
> many competing ideas exist out there that are closely or mildly related to
> this RFC.

Discussing prior-art for a proposal is entirely on topic.  We do it all 
the time when comparing PHP to other languages and their syntax, for 
example.  Internals should be informed by user-space usage patterns.

> This RFC has two primary goals in mind:
>
> 1) Expose the parsing/handling of the HTTP request to userland in a
> consistent way

It already is. It's the access TO that parsed data that is currently 
clunky.  That's a problem worth addressing.

> 2) Avoid having the request parsed/mangled at multiple levels during the
> request by presenting one central place to handle the parsing

This only applies to the body of a request; other properties have 
well-defined and not really variable parsing rules called HTTP.

A better way to parse the body is useful, and we've been discussing that 
in FIG.  Please look at the existing discussions and prior art before 
continuing.  That's also a much smaller, tighter discussion than 
request/response interfaces.

> These goals can not be achieved purely in userland, because you would
> potentially have to do the parsing step twice. I wish to make it possible
> for the user to override that with their own implementation just like they
> can override the Session handler with the Session interface.
>
> How we end up deciding to do that may change from my initial proposal, and
> that's fine, but let's focus on that rather than getting off topic about
> other third party efforts.
>
> Thanks!

Those 3rd party efforts are entirely on topic. That's the point.

--Larry Garfield