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
