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

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