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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
