httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <>
Subject Re: About Interim Response Headers (was: Content-Length header for 1xx status codes)
Date Thu, 08 Dec 2016 10:48:06 GMT

> Am 08.12.2016 um 11:25 schrieb Yann Ylavic <>:
> On Thu, Dec 8, 2016 at 3:12 AM, William A Rowe Jr <> wrote:
>> On Dec 7, 2016 6:23 PM, "Jacob Champion" <> 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.


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 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.


View raw message