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

This is only part of a thread. view whole thread
  110238
May 21, 2020 22:06 larry@garfieldtech.com ("Larry Garfield")
On Thu, May 21, 2020, at 4:53 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: > 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? > > > Regards, > > -- > Rowan Tommins (né Collins) > [IMSoP]
This makes complete sense to me. Whether it needs a formal RFC or not is above my pay grade, but I expect it would be just a formality if so. +1 --Larry Garfield