Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78545
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.180 as permitted sender)
User-Agent: K-9 Mail for Android
In-Reply-To: <CALWK-fjmz-fF3sF-eyrHJ=VBQXh1bBBDvkEemgFubzYJ+hesnQ@mail.gmail.com>
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> <CC36778A-6962-4CCF-8B64-EA5A37370A5A@ajf.me> <CALWK-fjmz-fF3sF-eyrHJ=VBQXh1bBBDvkEemgFubzYJ+hesnQ@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Date: Sat, 01 Nov 2014 14:13:42 +0000
To: internals@lists.php.net
Message-ID: <604DEB5F-35FF-46BE-9CAF-7681F0E19116@gmail.com>
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: rowan.collins@gmail.com (Rowan Collins)

On 1 November 2014 13:15:45 GMT, Damien Tournoud <damz@damz.org> wrote:
>On Sat, Nov 1, 2014 at 1:40 PM, Andrea Faulds <ajf@ajf.me> wrote:
>> > On 31 Oct 2014, at 18:37, Larry Garfield <larry@garfieldtech.com>
>wrote:
>> > IF internals wanted to add implementation, not just improving
>streams, something like the following would be much more useful:
>> >
>> > $request = http_get_request(PHP_STDIN); // or something
>> >
>> > Where $request is an object that implements the PSR-7
>RequestInterface (or at least the read-only parts of it), or something
>similar.  Then implementers can compose that object however they want.
>> > [...]
>>
>> This sums up my thoughts on this very well. Nobody needs to change
>how we parse the data. We just need better access to the results of the
>parsing.
>
>Alternatively, what I would see as extremely useful would be to be
>able to expose the "main loop" of the SAPI. Have a way (via an ini
>mechanism) to register a callback that is executed when a requests
>start processing. Essentially, similar to what is provided by WSGI
>(for Python) and Rack (for Ruby).
>
>The default implementation would be something like:
>
><?php
>function default_entrypoint($env) {
>  php\register_superglobal($env);
>  php\execute_script();
>}
>?>
>
>(with this callback executed in the scope of the new request)
>
>But you could override any of it if you wanted to, and that would pave
>the way nicely to more advanced PHP SAPIs (possibly evented) down the
>road.

This is actually quite an appealing idea; it provides a stepping-stone towards an evented SAPI without pre-empting other decisions which would need to be made (such as how global and static scopes would be handled). I particularly like the idea of exposing elements of default behaviour as non-magic functions, so that you could pass some other/modified request object to populate superglobals, for instance.

It could perhaps be implemented as a special function, which if present in the file targeted by the HTTP request (i.e. not via include()/require()) is called automatically, and passed a standard object providing access to the raw request.

I'm not sure how the response could best be managed so that it interacted smoothly with existing mechanisms; the function could optionally return a response object, but would perhaps need access to a magic object representing the default response built with echo, header_*() etc. Waiting for the entire response to be ready before streaming it to the SAPI isn't always desirable, either; I guess these are the kinds of issue FIG have been discussing...

In short, though, you would have an index.php file something like this:

<?php
 function __main(HTTPRequst $request, HTTPResponse $default_response) {
    require 'autoloader.php';
    $action = Router::selectAction($request->getQueryStringParam('action'));
    $custom_response = $action->process($request);
     return $custom_response;
}