Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
From: Stefan Eissing <stefan.eissing@greenbytes.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Subject: Re: About Interim Response Headers (was: Content-Length header for
 1xx status codes)
Date: Thu, 8 Dec 2016 11:48:06 +0100
References: <CACsi250j61arOtupHdqbX4uFq8CjE3NbNyR5SQemtpJiRN2_gg@mail.gmail.com>
 <de383041-fd8c-b07d-ad0b-4bbc1ec49703@gmail.com>
 <CACsi2536GDjqOnfVxDCdYwQCLmvU+CK39M_fwQzUmK+xekdCgg@mail.gmail.com>
 <2094ae26-d63b-9d7f-2f99-564b17762a91@gmail.com>
 <CACsi252Kfs7KbG9r2WM5A83zGhqcqwDBFqup15JTboNxhF4odA@mail.gmail.com>
 <4fb0bb83-bcb4-22d3-0074-8dcf7d0216d7@gmail.com>
 <CACsi253CcPY=Ntg78crdOh6PnRb7aW_9iTufi8+z-Zb2WGHBLw@mail.gmail.com>
 <CAKQ1sVPdeUC23HP_3eZ9e3_j_hNbXCSN4fC9qMsjuta5ZQABow@mail.gmail.com>
To: dev@httpd.apache.org
In-Reply-To: <CAKQ1sVPdeUC23HP_3eZ9e3_j_hNbXCSN4fC9qMsjuta5ZQABow@mail.gmail.com>
Message-Id: <E242C64C-04DF-4A9B-A8C3-E137A560268A@greenbytes.de>
archived-at: Thu, 08 Dec 2016 10:48:13 -0000


> Am 08.12.2016 um 11:25 schrieb Yann Ylavic <ylavic.dev@gmail.com>:
>=20
> On Thu, Dec 8, 2016 at 3:12 AM, William A Rowe Jr =
<wrowe@rowe-clan.net> wrote:
>> On Dec 7, 2016 6:23 PM, "Jacob Champion" <champion.p@gmail.com> =
wrote:
>>=20
>> On 12/07/2016 04:00 PM, William A Rowe Jr wrote:
>>>=20
>>> Consider for a moment the case of an HTTP/1.1 upgrade request
>>> unrecognized by a proxy agent.
>>=20
>>=20
>> It was my understanding that this is an impossible situation for a
>> conforming proxy, since Upgrade is hop-by-hop. What am I missing?
>>=20
>>=20
>> The fact that there is no way for us to predict what new headers we =
are
>> passed in the future are defined in the future to be hop-by-hop, =
which
>> result in a 105 response code with a similarly imponderable =
conundrum. No
>> way for RFC2068 servers to know 101 became a hop by hop unhandleable
>> response.
>=20
> "Connection: Upgrade, ..." is a MUST when the Upgrade header is used,
> so servers/proxies do know.

Exactly.

There are three things mixed in this dicussion:
1. what the HTTP/1.1 protocol allows and asks us to do
2. what we need to change for 2.4.24
3. what our implementation should be in the future

As to 1:=20
basically https://tools.ietf.org/html/rfc7231#section-6.2 says it all. =
HTTP/1.1 defines 1xx interim responses and requires clients, on =
receiving them, to act on the known and ignore the unknown ones and =
continue processing.=20

For HTTP/1.1, as a server, we should not generate 1xx interims on =
HTTP/1.1 connections without a really good reason. There is high =
probability on unasked and especially unknown 1xx breakage in HTTP/1.1 =
clients and proxies.=20

In HTTP/2, we are pushing to change that behaviour, due to the =
opportunities that 1xx responses present and the relatively small set of =
implementations. mod_http2 does fully support it in the upcoming 2.4.24.

As to 2:
I agree that our interim handling and generation could do with some =
love. But it is working well enough, from my point of view, that I would =
say we can release a 2.4.24 on it. Even the one item that William =
mentioned, a HTTP/1.1 client talking via mod_proxy_http2 to a backend, =
works correctly. mod_proxy_http2 does not forward 1xx responses to a =
HTTP/1.1 main connection.

As to 3:
Possibilities are endless. =46rom my PoV it was not simple to track down =
the working of our implementation when I worked on mod_http2 and =
mod_proxy_http2 and on the 1xx dependencies between them. I agree with =
the comments made that it is not clear which header are send out under =
which processing phase. However I think the possibility of modules/hooks =
to add headers to 1xx response should be there. The protocol allows it =
and we cannot peak into the future and see all uses cases. Just look at =
103 and the Link header.

What is unsatisfying from HTTP/2 implementation PoV is that interim =
responses need to be serialized and parsed again. That is a course for =
breakage and, since mod_http2 had to make its own parser, needs to be =
fixed. In the beginning, I though I could intercept the 1xx generation =
and skip the parsing. However some modules like mod_proxy_http sends =
down a HTTP/1.1 serialized format.

-Stefan