Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96165
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.26 cause and error)
To: internals@lists.php.net
References: <DE0439B3-29F4-4BC6-B92A-A7630BE17196@gmail.com>
 <1e5a2abd-0044-5d57-d4b2-ddbbd3577639@gmail.com>
 <CANaX5nd7SmT9Yx3pB0ZXyC8=NMMoSCAecu=Z8HtVb280hBvXPA@mail.gmail.com>
Message-ID: <9dff82a0-173f-2a04-5a9c-71166b6f572f@garfieldtech.com>
Date: Mon, 26 Sep 2016 23:55:28 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CANaX5nd7SmT9Yx3pB0ZXyC8=NMMoSCAecu=Z8HtVb280hBvXPA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Server-Side Request/Response Objects
From: larry@garfieldtech.com (Larry Garfield)

On 09/26/2016 10:52 PM, Davey Shafik wrote:
> On Mon, Sep 26, 2016 at 2:32 PM, Rowan Collins <rowan.collins@gmail.com>
> wrote:
>
>> On 26/09/2016 20:37, Paul Jones wrote:
>>
>>> tl;dr: Gauging interest in an extension for server-side PHP request and
>>> response objects (*not*  HTTP messages per se; see below) prior to writing
>>> an RFC for them on the wiki.
>>>
>> This sounds like an interesting project, but I have a few questions.
>>
>> First, the obvious one: why does this need to be an extension and/or built
>> into core? Are there reasons such as performance for implementing this in C
>> rather than PHP? Does it provide functionality that is hard to implement in
>> a userland library?
>>
>> You mention that it is not just an HTTP wrapper, but although you mention
>> researching other frameworks, I can't see any reference to PSR-7 [
>> http://www.php-fig.org/psr/psr-7/]. What do you see as the relationship
>> between your proposal and that standardisation effort?
>>
>> Regarding the design of the objects themselves, why is stdRequest
>> property-only, but stdResponse method-only? The asymmetry feels awkward to
>> me.
>>
>> I think the most interesting parts are those that attempt to rationalise
>> $_SERVER, and I think a library (or built-in functionality) devoted to
>> those could be very useful. Some of that overlaps with PSR-7, but that
>> standard doesn't go into depth on things like Accept headers,
>> Authentication, etc.
>>
>> Like I say, it's an interesting idea, but I'm not sure how it fits in with
>> the wider ecosystem.
>
> Additionally to this, we need to start thinking about what it means to move
> away from simple request/response architectures. In the age of WebSockets
> and HTTP/2 multiplexing w/Server Push, the likelihood of multiple responses
> for one request, or even responses with no associated request, are possible.
>
> I'd rather look at this as the target for this kind of exploration and
> implementation.
>
> - Davey

A point others have made in the past, and I have been convinced of, is 
that userspace is perfectly fine for this sort of work.  It doesn't need 
to be native for any reason other than standardization, which PSR-7 
already has covered.

What *would* be helpful is to expose the "parse stream to struct" logic 
that PHP uses to build the superglobals to user space. Basically, make 
it possible to replace Request::createFromSuperGlobals() with 
Request::createFromStream('php://stdin') (or something along those 
lines), for performance as that's the only expensive part of the 
process.  Parsing whatever that provides into a PSR7 object, an 
HttpFoundation object, or something else is then safe to do in userspace 
and evolve in user-space as needed.

It would also make it possible to parse an arbitrary stream (or maybe 
string?), not just php://stdin, which would help with long-running 
processes, HTTP2, etc. etc.  Perhaps there could even be an ini option 
(*ducks*) to disable the superglobals entirely and save that processing 
time.

I agree that Yet Another Request Struct(tm) offers little value at this 
point.

--Larry Garfield