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

This is only part of a thread. view whole thread
  111226
July 28, 2020 18:22 me@kelunik.com (Niklas Keller)
Hey all,

> > > Given that it's a very small change, the RFC is probably not necessary, > in > > which case it's not too late, however I'd like some clarification about > > what this actually offers over defaulting to 1.0. >
One thing it offers is detecting truncated responses. Servers will often respond without transfer-encoding: chunked / content-length for an HTTP/1.0 request, which leaves connection closure as only indication where the response ends. As we progress to HTTP/3 already, newer implementations might not implement 1.0 at all. If we're compatible with 1.1 already, there's no reason IMO not to advertise and use its features. That's a very reasonable question. The way I see it is this:
> > The risk of advertising 1.0 by default is that some software will have been > programmed to outright refuse that protocol version. I don't know of any > recent examples, but this bug report from 2007 was for a SOAP endpoint that > returned 505 Version Not Supported: https://bugs.php.net/bug.php?id=43069 > Notably, Dmitry's patch for that bug made sure the protocol context option > is honoured by ext/soap, but also specifically defaulted it to HTTP/1.1 as > of PHP 5.3. > > The risk of advertising 1.1 by default is that some software will respond > with a more complex response, and trigger some bug in our response parsing. > This was previously the case with detecting "Transfer-Encoding: chunked" > headers, for instance. By advertising 1.0, we may be benefitting from > servers "downgrading" their response. >
Do we handle 1XX responses, yet? https://tools.ietf.org/html/rfc7231#section-6.2
> In practice, a large amount of software appears to do neither, and simply > replies with an HTTP/1.1 response to a HTTP/1.0 request. This is why I talk > about "advertising" versions - in practice, the code is always acting as an > HTTP/1.1 client, e.g. sending "Connection: Close", and listening for > Transfer-Encoding, because it's increasingly rare for a server to actually > honour the 1.0 spec. >
This is what implementations should do, see https://tools.ietf.org/html/rfc7230#section-2.6 That section also says we should send 1.1, as we support it. Best, Niklas
> My main motivation for the change is that if someone was writing the > feature today, I don't think it would occur to them to default to 1.0, and > I think _new_ users would be less surprised at needing to opt into 1.0 than > into 1.1. > > Regards, > -- > Rowan Tommins > [IMSoP] >
  111236
July 28, 2020 20:48 rowan.collins@gmail.com (Rowan Tommins)
On 28/07/2020 19:22, Niklas Keller wrote:
> > Do we handle 1XX responses, yet? > https://tools.ietf.org/html/rfc7231#section-6.2
Yes, as of this patch a few years back: https://github.com/php/php-src/pull/2175/files
> This is what implementations should do, see > https://tools.ietf.org/html/rfc7230#section-2.6
I guess that's part of the "generous in what you accept" philosophy, since it makes no sense for a server to send a response chunked if the client didn't advertise 1.1 capabilities.
> That section also says we should send 1.1, as we support it.
Indeed, as far as I have been able to tell, the client code now complies with the spec for HTTP 1.1, although I struggled to find a list of minimum capabilities. Regards, -- Rowan Tommins (né Collins) [IMSoP]