HTTP/2 and Websocket support in 7.x versions

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,

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