On Tue, Jul 28, 2020 at 3:52 AM Rowan Tommins firstname.lastname@example.org>
> 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
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.