> On Jun 4, 2015, at 9:19 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> > wrote: > > I think we need to clarify some things: > > 1. ALPN is initiated by the client. When a client does not send ALPN as part > of client helo, the SSL alpn callbacks are not invoked and the server does > not send any ALPN information back. This is different from NPN. > > 2. SSLAlpnPreference is intended as the final word to make a choice when > either one ALPN callback proposes many protocols or of several callbacks > propose protocols. So, when mod_spdy and mod_h2 are active *and* the client > claims to support spdy/3.1 and h2, the SSLAlpnPreference determines what gets > chosen and sent to the client. This was not necessary with NPN as in that SSL > extension the client was making the choice. > > 3. Independent of the client proposal, as I read the spec, the server is free > to chose any protocol identifier it desires. This might result in the client > closing the connection. So, if the client uses ALPN and the server does not > want/cannot do/is configured not to support any of the clients proposals, > httpd can always send back „http/1.1“ since this is what it always supports. > > In this light, and correct me if I’m wrong, I see no benefit and only > potential harm by introducing a „SSLALpn on|off“ configuration directive. I > think the current implementation covers all use cases and if one is missing, > please point out the scenario.
Ultimately, what we need is a single configuration that defines how the host will respond to connections. I suggest that this should be done on a per-vhost basis if SNI is present, or a per-server basis if not. It should not depend on either ALPN or TLS being present. This needs to be defined by the server admin, not hard coded in the h2 code. We should also have a way for the end of a response to reset the connection to a possibly different set of protocols (i.e., Upgrade), but that's an independent concern. Hence, we might need a configurable way to ignore a client's ALPN, though I doubt that "SSLalpn off" is the right way to express that. Likewise, neither is SSLAlpnPreference. The server protocol(s) preference should be independent of the session/connection protocol. Our internal configuration and use of ALPN should be based on the overall configuration, not a configuration specific to the SSL code. Many configurations won't include ALPN. > As with the register once or on every connection optimization, yes, there > might be some performance to gain. But I think it is not so straightforward > to implement this, as not only the address and port influences this but also > the SNI that gets send in the client helo. So, one would have at least to > verify that registering an ALPN callback *after* the connection is open and > SNI has been received has any effect. I would hope that SNI is received before our connection is established (our connection is the virtual session over TLS, not the TCP connection). There shouldn't be any need to mess with SSL internals within mod_h2. Otherwise, it will be difficult to support h2c and h2 over SSH with the same code. ....Roy
