Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85611
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.26 cause and error)
Message-ID: <551B156C.1020502@garfieldtech.com>
Date: Tue, 31 Mar 2015 16:45:16 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <71.20.19097.3D1AA155@pb1.pair.com>
In-Reply-To: <71.20.19097.3D1AA155@pb1.pair.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] HTTP/2 and Websocket support in 7.x versions
From: larry@garfieldtech.com (Larry Garfield)

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