Re: [PHP-DEV] Re: HTTP/1.1 by default in PHP 8.0
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] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: HTTP/1.1 by default in PHP 8.0
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] >
Re: [PHP-DEV] Re: HTTP/1.1 by default in PHP 8.0
On Tue, Jul 28, 2020 at 3:52 AM Rowan Tommins 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
Re: [PHP-DEV] Re: HTTP/1.1 by default in PHP 8.0
Hi Rowan, Den 2020-07-28 kl. 10:52, skrev Rowan Tommins: Hi Sara, On Tue, 28 Jul 2020 at 00:24, Sara Golemon 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: HTTP/1.1 by default in PHP 8.0
On Tue, 28 Jul 2020 at 10:13, Eliot Lear wrote: > I think this is ok for a client. I'd feel differently about servers. > There may be other subtle changes between 1.0 and 1.1. Have you > reviewed those? > I did my best; see previous mails in this thread for my analysis. It's surprisingly hard to find a succinct summary of what _requirements_ are changed between specs, rather than just new features. As I say, though, that will only affect us if a server is strictly implementing both versions of the spec and behaving differently because we send HTTP/1.0. The fact that various HTTP 1.1 features are enabled in our client code by default suggests that is frequently not the case. Regards, -- Rowan Tommins [IMSoP]
Re: [PHP-DEV] Re: HTTP/1.1 by default in PHP 8.0
Hi Sara, On Tue, 28 Jul 2020 at 00:24, Sara Golemon 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]
Re: [PHP-DEV] Re: HTTP/1.1 by default in PHP 8.0
On Mon, Jul 27, 2020 at 5:25 PM Rowan Tommins wrote: > A couple of months ago I revived my suggestion to make stream wrappers > advertise HTTP/1.1 by default (full message below), and then Real Life > intervened and I didn't raise the PR. > > The implementation (which is a one-character change) is now here: > https://github.com/php/php-src/pull/5899 > > I realise it's now rather last-minute for 8.0, so if anyone thinks it > should have more careful thought, or an RFC, it will have to wait. If > there are no objections, though, it would be nice to have it merged > before the freeze. > > 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. Specifically, are there known servers which will refuse to serve 1.0 clients? Script authors have had the option of opting into 1.1 for some significant time now. Basically, what's the chance of something accidentally not working due to advertising 1.0 versus something not working due to advertising 1.1? If the changes are equal, I'd *personally* err in favor of status quo since those needing 1.1 have already opted into it, those needing 1.0 may not have. -Sara
