Re: HTTP/2 and Websocket support in 7.x versions

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