Re: [PHP-DEV] HTTP/1.1 by default in PHP 8.0

This is only part of a thread. view whole thread
May 23, 2020 19:42 (Ben Ramsey)
> On May 23, 2020, at 02:08, Davey Shafik <> wrote: > > dopOn Fri, May 22, 2020 at 3:58 AM Nikita Popov> > wrote: > >>> On Thu, May 21, 2020 at 11:54 PM Rowan Tommins> >>> wrote: >>> >>> Hi all, >>> >>> A few years ago, I posted a message suggesting that PHP improve support >>> for HTTP/1.1 in its stream wrapper functions: >>> >>> >>> A quick summary of the current situation: >>> >>> * HTTP/1.1 was officially standardised in January 1997, and most web >>> browsers had already implemented it by then >>> * PHP has a very simple HTTP client implementation, used by the "http:" >>> and "https:" stream wrappers, and also by extensions which make HTTP >>> requests, such as ext/soap >>> * The client implementation defaults to advertising HTTP/1.0 requests, >>> unless over-ridden by a stream context option >>> * Since a lot of servers only actually talk HTTP/1.1, the client mostly >>> acts as an HTTP/1.1 client even when advertising HTTP/1.0 >>> >>> >>> In my previous message, I identified four requirements in HTTP/1.1 but >>> not HTTP/1.0 that are relevant to a client: >>> >>> a) Send a "Host" header with every request. (RFC 7230 Section 5.4) >>> b) Support persistent connections, or send "Connection: Close" with each >>> request. (RFC 7230 Section 6.1) >>> c) Ignore 1xx status lines (notably, "100 Continue") "even if the client >>> does not expect one" (RFC 7231 Section 6.2) >>> d) Support "chunked" transfer encoding (RFC 7230 Section 4.1) >>> >>> >>> The PHP client now supports all four regardless of protocol version >>> configured, i.e. it always sends "Host:" and "Connection: Close" >>> headers; and always handles "100 Continue" and "Transfer-Encoding: >>> Chunked" if returned by the server. >>> >>> I would like to propose that the client advertises HTTP/1.1 in its >>> requests by default in PHP 8.0. Users can opt out of this behaviour in >>> a fully backwards- and forwards-compatible way if necessary using a >>> stream context option, e.g.: >>> >>> >>> >>> What are people's opinions? Does this need an RFC, or should I just >>> submit a PR if nobody objects? >>> >> >> Sounds good to me. Assuming there are no objections, feel free to just send >> a PR. >> >> @Eliot: Unfortunately we don't implement HTTP 2 in the http:// stream >> wrapper, so HTTP 1.1 is the best we can do there right now. We only provide >> HTTP 2 support through the curl extension. Implementing HTTP 2 support >> would certainly be a possibility, but I don't think it's particularly easy >> to do so without pulling in a dependency like nghttp2. >> >> @Max: I'm only guessing here, because I'm not familiar with the historical >> context, but I imagine part of the motivation is to support HTTP requests >> in a minimal build of PHP, which does not have any dependencies (that we do >> not bundle ourselves). >> >> We did actually provide an implementation of the http:// stream wrapper >> via >> curl for a long time, but dropped it at some point, because there were many >> subtle behavior differences to our native implementation. >> >> Regards, >> Nikita >> > > This is ridiculously timely as I've been spending my evening working on > HTTP/2 stuff in PHP. > > This might be a good time to reopen discussion of adding support for HTTP/2 > in PHP with the inclusion of libnghttp2. I posted a long time ago about > adding support for HTTP/2 to the CLI server and the http stream using > libnghttp2 [1]. > > I think PHP 8.0 would be a perfect opportunity to revisit this given that > HTTP/2 has now reached ~97% adoption[2] and HTTP/3 is on the horizon. > > 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. > > - Davey > > [1] > [2]
Agree 100% with Davey on this! -Ben