hi, On Tue, Mar 31, 2015 at 8:31 PM, Grégory Planchat <greg...@luni.fr> 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? > > 2. HTTP/2 response push and WebSocket > > 2.1 State of the art and Native HTTP server > > Another important feature is the push feature. How would it be possible to > implement in further versions of PHP, without having to reimplement the HTTP > server like the ReactPHP[4] project? > > Considering the fact that there is no enterprise-ready and performant > application loop manager integrated natively in PHP core (using either > forked or asynchronous), like Node.js's libuv, these solutions are destined > for very small APIs and applications. > > Since PHP 5.3, there is the -S option for starting an internal HTTP server. > Isn't there any plans to map this server to an userland API? This server has > in fact all the logic needed by applications like ReactPHP[4], which has to > reimplement it(!). > > Shouldn't there any other solution planned in PHP 7.x? > > 2.2. Solution 1: Implementing server from the ground with OS abstraction and > application loops > > Solution of implmeenting from the ground the HTTP server is what ReactPHP > did and is for now the most used solution. Some would say that these issues > should be kept in the userland, but please, read to the end. > > Furthermore, integrating in the core an OS-abtracted API for process > management and asynchronous I/O could be a big performance jump, with an > extension being to ext/pcntl what PDO has been to ext/mysqli in PHP 5.x. > > As I wrote previously, Node.js has libuv which started as an abstraction > layer for Node's to libev and Windows and became a full featured OS > abstraction layer for process and I/O management. > > Shuhei Tanuma (with the help of other contributors) has implmented an > experimental binding named ext/uv[5] that could be a start to implment a > similar feature set in PHP. I used it for a while in a personal and > experimental project, it is functional despite of some (very rare) crashes > (and IMO a missing OOP-style API, which is more a personal taste than an > issue). > > In the same vein, we have pcntl[6], eio[7], ev[8], libevent[9], > pthreads[10], working in their own way but no uniform API, some use > functional style, others are OOP style and there is maybe interoperability > issues and feature overlapping (I did not test all of them in a single > project). Some even aren't integrated in the standard release and are > availiable on PECL only. > > As long as all these features are currently in extensions or in a SAPI, why > wouldn't it be integrated in an unique extension/API? > > The changes in the SI architecture between PHP and the web server would be > to transform the CGI interconnections to classical HTTP proxy connections. > > 2.3. Solution 2 : Define some other way, extending the SAPIs and/or the CGI > API > > I can't tell if it is even possible to implment this, as long as the current > architecture depends on the underlying layer sollicitations (HTTP > server/CLI/ect...). > > Currently, PHP itself doesn't decide to send some data to the client such as > push features, it must wait for its caller to be invoked, or manage the full > application stack. Maybe it is all the request lifecycle that has to be > rethought from the ground as an application of 2015 is radically different > from a 1995 application (or even from 2005). > > 3. Conclusion > > Maybe there are other solutions. HTTP/2 has been released and a massive > migration is about to come in the next 2 years. PHP has to move forward and > implement new features or other platforms will be preferred on medium to > large scale projects (including Node.js, Python and Ruby). > > I know some of you are working on large web companies like Google, Facebook > or Twitter and you may be more aware about their plans for migrations than > me. All I can tell about official statements is that they are planning to > migrate, if it isn't already done.
Some notes: As other said already there is no plan yet for http2 support in php (7.0). It is not an easy task. I like the curl's approach as an attempt to make it as transparent as possible for our users. I would also try to avoid to re-implement everything ourselves, at least for the 1st shots. I am surprised that your mail do not mention https://nghttp2.org/, which is the de facto standard implementation for http2. I did not manage to sit on it but that was my plan for 7.0 when we discussed the TODOs, more 7.1+ now. Supporting multiple requests at the same time, be with nghttp2 or other is possible, we already do that. Talking about client side http2 only obviously :) I did not think yet about how PHP could be better to actually allow multiple requests, server side, first gut feeling is that it is not really PHP job to deal with that but one layer higher. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
