Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111226
MIME-Version: 1.0
References: <e827814f-8a4e-4388-bc82-47c244aad978@gmail.com>
 <9d28ade6-1a70-9850-3bc0-64050c0dcbe4@gmail.com> <CAESVnVrajMYWoV9ce6xndsXKszTseP2UJcK_6VN0e_hGDa6SYg@mail.gmail.com>
 <CALKiJKq3X+jV3r9dMFOu_FynpZCjj7j2Bqk7SvAH4mb7uQdfZg@mail.gmail.com>
In-Reply-To: <CALKiJKq3X+jV3r9dMFOu_FynpZCjj7j2Bqk7SvAH4mb7uQdfZg@mail.gmail.com>
Date: Tue, 28 Jul 2020 20:22:13 +0200
Message-ID: <CANUQDCi=NEdQ0gKDwPYFWRLqy90CET_N=R7qbakHsPsVu3EObQ@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>, Sara Golemon <pollita@php.net>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000035854905ab848bd9"
Subject: Re: [PHP-DEV] Re: HTTP/1.1 by default in PHP 8.0
From: me@kelunik.com (Niklas Keller)

--00000000000035854905ab848bd9
Content-Type: text/plain; charset="UTF-8"

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]
>

--00000000000035854905ab848bd9--