On 09/26/2016 10:52 PM, Davey Shafik wrote:
On Mon, Sep 26, 2016 at 2:32 PM, Rowan Collins <rowan.coll...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
