On 7/24/2013 6:41 AM, Zhong Yu wrote:
Hi there,
HTTP/2.0 draft (based on google's SPDY) requires the use of a new TLS
extension (ALPN), see
http://tools.ietf.org/html/draft-ietf-httpbis-http2-04#section-3.3
The current javax.net.ssl API does not support that, so it'll be a
problem for someone trying to implement the HTTP/2.0 draft on Java
platform. Is there a remedy to that?
Both HTTP 2.0 and ALPN extension are in early stage. Java does not
support ALPN at present. But for a none-product environment, it is
doable with a few update to OpenJDK by making use of the handshaking
session.
If javax.net.ssl needs further development to be able to support ALPN,
would you give a rough estimate on when it could be released? And
would it be back ported to earlier versions of Java?
Looks like, to support ALPN, javax.net.ssl needs to design new APIs. As
make it hard to backport to earlier releases of Java.
Marketing and customer requirements are important factors when we design
new features.
What kind of API change do you envision that's necessary to expose
ALPN negotiation process to applications?
I have no think about this too much. Probably, we might only need pulic
APIs to expose the ALPN in handshaking session (SSLSession), and an
handler to accept or reject the request (or have TrustManager do it
instead).
SSLSocket.getHandshakeSession()
ExtendedSSLSession.getAppProtocols()
Note that HTTP/2.0 is in very early stage; it's possible that the
requirement of ALPN could be relaxed if there's difficulty to
implement it on popular platforms; see this thread:
http://lists.w3.org/Archives/Public/ietf-http-wg/2013JulSep/0425.html
I have not read this thread. Is there any one suggest to use START TLS
as an alternative solution?
Xuelei
Thank you very much,
Zhong Yu
