Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96170
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.177 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
In-Reply-To: <CANeXGWU67RKPvRdyLaigdTC+8d3H19Doph07fUuLrH_+W18quw@mail.gmail.com>
Date: Tue, 27 Sep 2016 03:13:54 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <45813C0E-4D1A-4F0D-ABB1-B454AFAEC90E@gmail.com>
References: <DE0439B3-29F4-4BC6-B92A-A7630BE17196@gmail.com> <CANeXGWU67RKPvRdyLaigdTC+8d3H19Doph07fUuLrH_+W18quw@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] Server-Side Request/Response Objects
From: pmjones88@gmail.com (Paul Jones)

Hi all,

First, I want to reiterate that my initial desire was to submit this to =
PECL, to give the project some exercise before bringing it to internals. =
If someone here can nudge the PECL folks about my account request, =
that'd be appreciated. Otherwise, I'm happy to continue the discussion =
here.

Now, on to the questions and criticisms.

* * *

> On Sep 26, 2016, at 16:10, Korvin Szanto <korvinszanto@gmail.com> =
wrote:
>=20
> Personally I would prefer complete HTTP message objects similar to =
existing PSR-7 implementations be added perhaps alongside these simple =
classes you've proposed.

Mike Wallner notes his pecl_http work, which I think is good for =
complete HTTP messages.

* * *

> On Sep 26, 2016, at 16:32, Rowan Collins <rowan.collins@gmail.com> =
wrote:
>=20
> This sounds like an interesting project, but I have a few questions.
>=20
> 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?

The part that's hard to do in userland is public read-only properties =
that cannot be subverted by child classes.  As to building it into core, =
I think it'd probably be better in PECL first, but my application there =
has been ignored so far (though maybe I've not waited long enough).


> 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?

I did use it as a research subject, but I failed to include it in my =
notes; I will add it.

I was a sponsor on PSR-7, and I've worked with implementations since =
before the PSR was finalized. I put together the Relay middleware =
dispatcher, and some middleware pieces, and some applications, all using =
PSR-7, so I'm relatively familiar with its ins and outs.

However, I have come to think of it as "not having lived up to its =
promise." That's not to denigrate MWOP, its lead author, whom I =
encouraged throughout the PSR process. But the PSR-7 claim of =
"immutability" turns out to be only partly true; instead, it is =
quasi-immutable, and so it has the problems that come with both =
mutability and immutability. There are some other problems, which if you =
press me on I'll go into, but not eagerly and only with trepidation.

This work steps back a little bit, to survey the actual implementations =
of server-side requests and responses in userland, and bring together =
their similarities (with a very little bit of refinement), instead of =
building an entirely new and not-thoroughly-examined way of doing =
things.


> Regarding the design of the objects themselves, why is stdRequest =
property-only, but stdResponse method-only? The asymmetry feels awkward =
to me.

Yeah, I get that. They use PHP itself as the example, where the =
superglobals carry all the request-related information, and global =
functions handle all the response-related activity. Part of the idea is =
to make using StdRequest and StdResponse "feel" a bit more like using =
the superglobals and global functions, while still corralling the =
related information into its own space inside an object.


* * *

>=20
> On Sep 26, 2016, at 16:45, Michael Wallner <mike@php.net> wrote:
>=20
> Did you include pecl/http in your research?

I did, but I failed to note it. I will do so.


> It looks like it covers most of that already, if not all.
> I know you said *not* HTTP messages per se, but I don=E2=80=99t see a =
lot of a difference.

One difference regarding StdRequest is that everything is exposed as =
read-only public properties. All of the frameworks/libraries I looked at =
had equivalents of this:

    $value =3D $request->getPost($key, $default_value);

That's to provide a default value if a particular $_POST key is not =
available.  However, under PHP 7, the ?? operator makes that kind of =
method unnecessary:

    $value =3D $request->post[$key] ?? $default_value;

Further, StdRequest includes things that are not part of HTTP messages =
(e.g. all $_ENV values, and some $_SERVER values).

The main difference regarding StdResponse is that instead of attempting =
to mimic an HTTP Message model, it mimics PHP functionality, except =
buffering the calls instead of sending them right away. (There are some =
added convenience methods as well, drawn from the research subjects.)


* * *

> On Sep 26, 2016, at 16:52, Davey Shafik <davey@php.net> wrote:
>=20
> 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've spoken with Davey, and the summary seems to be that server-push is =
possible, though in an impoverished way, via Link headers. Those can be =
added with header(), which means they can be added with =
StdResponse::setHeader().

As far as the rest, they are the subject of future work from Davey, =
which I look forward to, and will be happy to incorporate as it becomes =
available. (Davey, please correct me if I got that wrong.)

> I'd rather look at this as the target for this kind of exploration and
> implementation.

To be clear, the StdRequest/StdResponse classes are not intended as =
exploration; they are "summaries" of existing work in the field.


--=20

Paul M. Jones
http://paul-m-jones.com