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,