Hi, On Wed, Jun 3, 2015 at 8:23 AM, Xuelei Fan <xuelei....@oracle.com> wrote: > Per section 4, RFC 7301: > "... The > "application_layer_protocol_negotiation" ServerHello extension is > intended to be definitive for the connection (until the connection is > renegotiated) and is sent in plaintext to permit network elements to > provide differentiated service for the connection when the TCP or UDP > port number is not definitive for the application-layer protocol to > be used in the connection. By placing ownership of protocol > selection on the server, ALPN facilitates scenarios in which > certificate selection or connection rerouting may be based on the > negotiated protocol." > > Per my understanding, application protocol should be negotiated before > cipher suite and protocol version negotiated.
This is not possible for HTTP/2. Application protocol negotiation MUST happen *after* the TLS protocol and the TLS cipher are negotiated. > And the connection may be > rerouted (even to different machines) for further operation. The > requested application protocols list should be the only information for > the selection of a suitable application protocol. Not sure what you exactly mean here, but you can't pick the HTTP/2 protocol unless you have the TLS protocol and TLS cipher available. So *only* the list of protocol sent by the client is not enough for HTTP/2, we would need additional contextual information. What a HTTP/2 aware load balancer written in Java that offloads TLS would need to do is to negotiate the TLS protocol, negotiate the TLS cipher, *then* negotiate the application protocol (whether "h2" or "http/1.1"), and with the last information pick a backend server, typically forwarding clear text bytes to the backend. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
