> On May 23, 2020, at 02:08, Davey Shafik <da...@php.net> wrote:
> 
> dopOn Fri, May 22, 2020 at 3:58 AM Nikita Popov <nikita....@gmail.com>
> wrote:
> 
>>> On Thu, May 21, 2020 at 11:54 PM Rowan Tommins <rowan.coll...@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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to