Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85615
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: internals@lists.php.net,Larry Garfield <larry@garfieldtech.com>
Message-ID: <551B288E.5090203@luni.fr>
Date: Wed, 01 Apr 2015 01:06:54 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
References: <71.20.19097.3D1AA155@pb1.pair.com> <551B156C.1020502@garfieldtech.com>
In-Reply-To: <551B156C.1020502@garfieldtech.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] HTTP/2 and Websocket support in 7.x versions
From: gregory@luni.fr (=?UTF-8?B?R3LDqWdvcnkgUGxhbmNoYXQ=?=)

Le 31/03/2015 23:45, Larry Garfield a écrit :
> On 3/31/15 8:31 AM, Grégory Planchat wrote:
>> Hi,
>>
>> I've been reading about PHP7 RFC ans I did not see anything about HTTP/2
>> support in any threads on internals nor the wiki. I'm aware that HTTP is
>> the responsibility of the underlying web server, but there are new
>> *important* features to consider.
>>
>> I know the feature list for PHP7 is now frozen, but this is an important
>> feature for upcomimg 7.x versions, as long as this *IS* the future of
>> the web.
>>
>> 1. HTTP/2 multiplexing
>>
>> HTTP/2 comes with document and resources multiplexing on one unique TCP
>> connection stream [1]. Support is coming quickly in web servers[2][3],
>> by late 2015 Apache and Nginx should support natively or via a module
>> HTTP/2, just at the time PHP7 should be released.
>>
>> To set the context, currently with HTTP/1.x the images, css, js, and
>> other resources are just referenced in the HTML and then loaded by the
>> HTTP client once the HTML has been requested and loaded, but there is no
>> explicit link between documents on the server side. As a result, each
>> resource consumes one TCP stream.
>>
>> Some optimisations exists like Connection: keep-alive, but it just save
>> some TCP handshakes, the client still waits the loading of the HTML
>> *BEFORE* requesting the js/css/images/resources. There is also a data://
>> protocol for small size resources, but it is not practical at all and
>> suffers from partial support in the browsers.
>>
>> How would one specify which resources should be sent *WITH* the
>> generated HTML? Is there anything in the FastCGI protocol to support
>> these sort of features (via header or metadata or something else)?
>> Alongside, is there something equivalent that would be possible to do in
>> the PHP/Apache module?
>
> We discussed this briefly in the FIG regarding PSR-7.  It looks like H2O
> and nginx have both adopted a standard of using a Link header with rel
> preload to indicate "HTTP2, push this along with it if you can".
>
> So if your PHP code just sends a bunch of extra Link-preload headers,
> the web server should figure it out and do the work for you if it can.
> (And if it doesn't, and the browser ignores it too, ignored headers are
> ignored.)
>
> So that part at least is already possible.
>
> Push messages and WebSockets are an interesting problem space, though,
> and I agree some careful thinking is needed there.  It's related to, but
> distinct from, the questions around native async/non-blocking PHP (which
> I also fully support in concept).
>
> --Larry Garfield

HI Larry,

I was not aware of this header, thanks for the infomation, at least it 
solves easily one of my points.

Now, about WebSockets and HTTP/2 messages push, yes it needs to be 
thinked carefully.

At this stage I'm just fixing some ideas, you can eventually tell me if 
you agree with them or not.

* Maybe some feedback could be taken from ReactPHP development team 
about the needs of an (exsisting) asynchronous application in the PHP world.
* Asynchronous I/O is mandatory for an userland daemon as seen in 
ReactPHP, but there could be some other pathes such as a specific SAPI 
running worker threads (in fact, the networking tasks would be kept out 
of userland scope by the SAPI itself, just like what the CLI SAPI with 
-S option does for classical HTTP requests, each worker would be a 
callable, or even better: a generator exploiting yield's bidirectional 
messaging)
* PSR-7, when published, could be an interesting starting point about 
message push, to think it deeper if the async I/O option is chosen
* WebSocket and WAMP protocols have also to be implemented by this SAPI 
if this option is chosen. As a consequence further protocols updates 
will have to be handled by @internals team as long as userland code does 
not handle it
* During PHP7 discussions, some mentioned Zephir to build extensions. 
Sara Golemon told me on Twitter she was working on a common API for HHVM 
and php-src. Maybe this set of features could be implemented with these 
emerging solutions

Grégory Planchat