httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <>
Subject Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgrade tls
Date Tue, 08 Dec 2015 06:36:43 GMT
Wow, you have been busy in my sleep...

I will respond to individual messages later in my office. From what I got overall:

- I completely agree with Yann, request bodies, 100 continue or not, are sent using the original,
pre-upgrade protocol, e.g. http/1.1
- until the body is read, 101 may be sent back, but afterwards the downstream is talking the
new protocol, while the upstream can only start doing so after the last request byte
- this makes upgrades on requests with bodies awkward for both parties. the approach of setaside
nnn bytes is bad for interop as there is no standard what nnn is supposed to be, leading to
failed requests varying by implementation or even size specific configuration. For h2 therfore
all server implementors on the HTTP WG list at that time agreed to body-less upgrades only.

- In case a client wants to talk to a known server implementation and is concerned about efficiency,
I'd recommend http2 direct mode. 24 initial bytes and you have http2.
- as Jacob pointed out, some protocols need deeper inspections/other responses before sending
out 101. So, I think making that part of the protocol switch handler is better.


> Am 08.12.2015 um 03:50 schrieb William A Rowe Jr <>:
> Sorry it took so long to respond to this earlier post, some of this might have already
been covered...
>> On Mon, Dec 7, 2015 at 1:03 PM, Stefan Eissing <>
>> Think about CORS restrictions and other stuff.
>> - I think its the protocol handlers job to deal with any request body.
> Strongly disagree, because 1. the protocol switch mechansim isn't the content handler
of the originating request, the request body is a request-level entity, and 2. TLS gave you
a perfect illustration of altering the connection stack to continue using the core protocol
> In the case of h2c, or even a mod_echo Upgrade: echo mechanism, the entire request/response
is going to be handed off to a new protocol stack, I understand that.  But that is one of
several use cases here, and that new protocol stack is going to consume the network pipe and
close it, I trust?!?  And return the appropriate status that the connection is gone even if
it leaves the old code to mop up, e.g. lingering_close.
>> For h2 upgrade, for example, the switch is only offered for requests without body.
> Well, h2c is advertised on the first request with or without a body, and then never again.
Other modules must advertise, e.g. in conjunction with the 426 Upgrade Required.
> In fact, how do you propose to handle an authentication case with h2c living in near
the handler phase, when it will alert during the authnz phase that http1.1 has been disallowed/h2c
is required for a particular resource, and that upgrade (which could have occurred in the
post-read-request phase) has not yet occurred during auth?
>> - moving things to post read sounds tempting, however I'm not sure if we want to
upgrade on non-authed request or not, for example.
> This is transport layer, yes, we always address the protocol without consideration as
to authnz; the same as we decode gzip irrespective of client auth.  The actual requests over
h2c (or http/1.1) are *each* still subject to auth per-request.
> I can't see a justification for excluding a client other than the user agent identifier
(known inoperable agent), otherwise h2c benefits the client-server performance and there is
no obvious reason to prevent it?
>> I am not sure what else we do in post read, maybe someone else has an opinion about
that. It certainly looks nicer in the OPTIONS * case. 
> The most critical thing for all of us to pay attention to is the setenvif logic and mod_headers
injection, things that are there to deliberately affect the initial read and processing of.
 The admin may want to trick httpd into *not* honoring upgrades from specific user agent signatures
that are known-wonky, or when other request headers are present.  So I suggested HOOK_LAST,
although a slightly different order could work.  We carefully inject mod_ssl (not upgrade,
but the core read request hook) to fall after mod_setenvif, but otherwise at HOOK_MIDDLE.

View raw message