Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:85587 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 33856 invoked from network); 31 Mar 2015 14:11:48 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 31 Mar 2015 14:11:48 -0000 X-Host-Fingerprint: 78.217.8.218 gaz43-2-78-217-8-218.fbx.proxad.net Received: from [78.217.8.218] ([78.217.8.218:16442] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 67/B2-19097-32BAA155 for ; Tue, 31 Mar 2015 09:11:48 -0500 To: internals@lists.php.net,Daniel Lowrey Message-ID: <551AAB20.6060100@luni.fr> Date: Tue, 31 Mar 2015 16:11:44 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Posted-By: 78.217.8.218 Subject: Re: HTTP/2 and Websocket support in 7.x versions From: gregory@luni.fr (=?UTF-8?B?R3LDqWdvcnkgUGxhbmNoYXQ=?=) Le 31/03/2015 15:56, Daniel Lowrey a écrit : > HTTP/2 is entirely outside the scope of the PHP web SAPI as it currently > exists. The protocol impacts the actual HTTP server and has nothing to do > with the SAPI runtime which is simply handed information about the HTTP > request once the server parses it. The protocol used to communicate those > details between the client and the HTTP server does not concern the web > SAPI. There is no need for any sort of "support for h2" in PHP; it's the > web server's concern. Apache and nginx will add support for h2 and PHP will > continue working as it always has. > > That said, the php web SAPI derives exceedingly little benefit from the > advent of HTTP/2.0. h2 is designed to allow multiplexing of many requests > over the same TCP connection but the PHP web SAPI still has the same > bottleneck it had before h2: one thread/process per request. > > As for websockets, you *can* do that using the web SAPI right now if you > wished but this would be inadvisable because long-lived connections will > quickly fill the bottleneck in every PHP web application (concurrent > threads/processes for each "request"). > > Instead, the appropriate solution for websockets would be to implement a > socket server directly in the CLI that speaks the websocket protocol. > > Would it be useful to have raw incremental parsing functionality for > HTTP/1.1, HTTP/1.2 and websocket protocols available in userland? Sure, but > this falls more in the realm of an extension than anything else as few > people are implementing full-blown http and websocket servers in the CLI > right now. > Hi Daniel, Your message is focusing on the solution I can find today in the wild, not about the need mys previous message was about, namely multiplexing and message push. Anyway I'm aware of this and I understand your point, but why should'nt we be able, natively, to exploit HTTP/2 enhancements, particurlarly resources multiplexing and data push? Why woud we restrain to exploit 20 years old protocol features, deliberately omitting new ones that are already implemented on other platforms? Grégory