Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110270
To: PHP Internals <internals@lists.php.net>
References: <e827814f-8a4e-4388-bc82-47c244aad978@gmail.com>
 <CAF+90c9Z60e42dnvMp5HC=70irxKFW0g6RvEAd0k=xdeAkYuAQ@mail.gmail.com>
 <CANaX5ncGdoKJ4RyQpiQUqG_GQQyBFkny5S7MPCGs6uV=Ho1CnA@mail.gmail.com>
Message-ID: <2635b2ea-fe04-299e-d24e-d20917f9c0d2@gmail.com>
Date: Sun, 24 May 2020 16:05:19 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <CANaX5ncGdoKJ4RyQpiQUqG_GQQyBFkny5S7MPCGs6uV=Ho1CnA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] HTTP/1.1 by default in PHP 8.0
From: rowan.collins@gmail.com (Rowan Tommins)

On 23/05/2020 08:08, Davey Shafik wrote:
> This is ridiculously timely as I've been spending my evening working 
> on HTTP/2 stuff in PHP.
> [...]
> I believe that HTTP/2 has the potential to dramatically change how we 
> serve content on the web, and PHP should jump on the bandwagon.


Hi Davey,

I'm glad someone's working on this, because PHP should definitely be 
trying to keep up with such things.

My only hesitation is that other than as a proof-of-concept, just 
allowing 'protocol_version'=>2 as a stream option isn't going to bring 
much advantage, because it doesn't give access to any of the interesting 
new features - it's still a single, one-way, synchronous request.

Given it's always been a web programming language, PHP has surprisingly 
poor native support for HTTP. On the server side, we have the SAPI 
layer, which delegates most of the protocol to external applications in 
generally CGI-type ways. On the client side, we have the very minimal 
stream wrapper (which doesn't even support pipelining with 
Connection:Keep-Alive), or some painfully low-level bindings around libcurl.

To really make use of HTTP/2, I would imagine both would need quite 
significant re-thinks: On the server side, can the SAPI and FastCGI 
definitions be extended, or do they need to be replaced, as Python 
defined ASGI [1] to replace WSGI? On the client side, should there be a 
better built-in HTTP client, whether based on libcurl or lower-level 
pieces like nghttp; or do we keep it low-level and expose nghttp2 itself 
in some way?

[1] https://asgi.readthedocs.io/en/latest/introduction.html

Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]