[jsr369-experts] Re: [servlet-spec users] Re: Question about TLS 1.2 Application-Layer Protocol Negotiation Extension

From: Mark Thomas <markt_at_apache.org>
Date: Tue, 16 Dec 2014 15:33:04 +0000

On 16/12/2014 14:23, Edward Burns wrote:
>>>>>> On Tue, 09 Dec 2014 12:42:17 +0000, Mark Thomas <markt_at_apache.org> said:
> MT> On 08/12/2014 20:44, Edward Burns wrote:
>>>>>>>> On Thu, 27 Nov 2014 13:49:03 +0900, Eugene Chung() <euigeun_chung_at_tmax.co.kr> said:
> EC> HTTP/2 requires ALPN extension(rfc7301) for HTTP/2 over TLS.
> EC> But Servlet 4.0(Java EE 8) will be based on Java SE 8, which is already
> EC> released.
> EC> Java SE 8, exactly JSSE in it, doesn't support ALPN extension.
> EC> I have been investigating but I couldn't find the way to use ALPN in a
> EC> standard fashion for container developers.
> EC> Is there any plan for this? (endorsed JSSE for Java SE 8?)
> EC> Or any other standard mechanism that I don't know?
> EB> My plan of record is to leave this as an implementation detail. Yes, I
> EB> know there is an ALPN client coming in Java SE 9, but we will be
> EB> sticking with Java SE 8 as our base.
> MT> That is a pretty large implementation detail. Is there nothing we can do
> MT> here in terms of requesting a back-port of the ALPN client to Java
> MT> 8?
> I am willing to try. I must set one precondition before I can credibly
> make such a request: establish a precedent.

Why do we need a precedent? That creates a chicken / egg problem.
Something has to be first. Why not this?

Does it have to be part of the standard release? Could it be in some
form of add-on much like JSSE was when it was first introduced?

If this remains a container concern then - given that the implementation
is going to have to be specific to at least the JRE vendor if not the
specific JRE release - this creates a huge amount of work for container
implementers and/or significantly reduces the number of JREs that JavaEE
8 implementations will be able to run on.

Another option is drop HTTP 2.0 support until JavaEE 9. I do not think
that is an option we should pursue.

> Is there any precedent for
> such a large new feature, with significant public API, to be introduced
> in a "dot release" of Java SE? I know of none off the top of my head,
> but I know I have many gaps up there, particularly the older I get.

None come to mind.