> Am 08.12.2016 um 11:25 schrieb Yann Ylavic <ylavic....@gmail.com>: > > On Thu, Dec 8, 2016 at 3:12 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: >> On Dec 7, 2016 6:23 PM, "Jacob Champion" <champio...@gmail.com> wrote: >> >> On 12/07/2016 04:00 PM, William A Rowe Jr wrote: >>> >>> Consider for a moment the case of an HTTP/1.1 upgrade request >>> unrecognized by a proxy agent. >> >> >> It was my understanding that this is an impossible situation for a >> conforming proxy, since Upgrade is hop-by-hop. What am I missing? >> >> >> 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. > > "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: 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. 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. 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. From 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
