Re: Server-Side Request/Response Objects

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