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

This is only part of a thread. view whole thread
  111213
July 28, 2020 08:52 rowan.collins@gmail.com (Rowan Tommins)
Hi Sara,

On Tue, 28 Jul 2020 at 00:24, Sara Golemon <pollita@php.net> wrote:

> > 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. >
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. 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. 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]
  111215
July 28, 2020 10:15 bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)
Hi Rowan,

Den 2020-07-28 kl. 10:52, skrev Rowan Tommins:

> Hi Sara, > > On Tue, 28 Jul 2020 at 00:24, Sara Golemon <pollita@php.net> wrote: > >> 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. >> > > 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. > > 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. > > 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,
I think there is also a consistency argument to make here. If the code behaves like HTTP 1.1, I think it also should advertise it as such. So go for it! Regards //Björn L
  111224
July 28, 2020 16:45 pollita@php.net (Sara Golemon)
On Tue, Jul 28, 2020 at 3:52 AM Rowan Tommins collins@gmail.com>
wrote:

> 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. > > 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. > > The "servers have a bad habit of ignoring this anyway" argument is probably true, but it sort of takes the wind out of BOTH of the other two
points. :) I'm not going to object to merging it, the worst case scenario is that a few app developers will learn the protocol version option exists and have to set "1.0" manually. Even that is a low probability. Probably better in the long-term to inch our way forward and advertise a protocol that was introduced... checks notes... 21 years ago. -Sara
  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]