Den 2020-07-28 kl. 10:52, skrev Rowan Tommins:
> Hi Sara,
> On Tue, 28 Jul 2020 at 00:24, Sara Golemon <email@example.com> 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.
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
Regards //BjÃ¶rn L