> On May 23, 2020, at 02:08, Davey Shafik <davey@php.net> wrote:
>
> dopOn Fri, May 22, 2020 at 3:58 AM Nikita Popov <nikita.ppv@gmail..com>
> wrote:
>
>>> On Thu, May 21, 2020 at 11:54 PM Rowan Tommins <rowan.collins@gmail.com>
>>> 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:
>>> https://externals.io/message/96192
>>>
>>> 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.:
>>> https://gist.github.com/IMSoP/a685fed6589435530102d57138755511
>>>
>>>
>>> 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] https://externals.io/message/89932
> [2] https://caniuse.com/#search=http%2F2
Agree 100% with Davey on this!
-Ben