On 9/25/2015 9:14 PM, Simone Bordet wrote: > On Fri, Sep 25, 2015 at 2:46 PM, David M. Lloyd <david.ll...@redhat.com> > wrote: >> > Well, SNI already basically works this way, so it's not so great a stretch. > I don't follow ? > SNI has APIs in JDK 8, you don't use SSLExplorer at all.
There are two typical cases for SNI and ALPN. One is that the same server is used for difference SNI/ALPN. Another one is that different server is used for different SNI/ALPN. For example, there is a TLS server 101.101.1.1 for delegation. If SNI www.example.com get requested, the delegation server may redirect the connection to 192.168.1.100 (provide the service for www.example.com). If SNI www.another.com get requested, the delegation server may redirect the connection to 192.168.1.101 (provide the service for www.another.com). Similarly, ALPN need to support the case as above. Another example, there is a server 101.101.1.1. If SNI www.example.com get requested, the server would act as the service for www.example.com. If SNI www.another.com get requested, the server would act as the service for www.another.com. Similarly, ALPN also need to support the case as above. Actually, it was a puzzle to me: whether a concrete server can support both HTTP/2 and HTTP/1.1, or not. If HTTP/2 mode of the server does not work, is it OK to fall-over to use HTTP/1.1 mode? I did not get the answer from the HTTP/2 spec. The current design is based on the idea that a concrete server may support both HTTP/2 and HTTP/1.1 at the same time, and fall-over mode is necessary. Otherwise, the API and implementation can be simplified a lot. Xuelei
