jsr369-experts@servlet-spec.java.net

[jsr369-experts] Re: What to do about ALPN? (was: Question about TLS 1.2 Application-Layer Protocol Negotiation Extension)

From: Edward Burns <edward.burns_at_oracle.com>
Date: Wed, 7 Jan 2015 12:25:51 -0800

I'm attempting to close out the discussion on this thread. I'll take
each point in turn.

SECTION: h2c support

>>>>> On Wed, 17 Dec 2014 13:11:40 +1100, Stuart Douglas <stuart.w.douglas_at_gmail.com> said:

SD> So one thing I am not really clear on is what we are actually going to
SD> require in Servlet 4 / EE8, in particular:

SD> - Is HTTP2 a mandatory part of Servlet 4? i.e. you won't be certified
SD> compliant unless you support it

EB> The current plan of record is that HTTP/2 support is mandatory for
EB> Servlet 4.0. This means h2 and h2c.

>>>>> On Thu, 18 Dec 2014 17:40:12 -0500 (EST), Stuart Douglas <sdouglas_at_redhat.com> said:

MT> Given that, do we want to require containers to support h2c?

EB> While browsers do represent the bulk of software interacting with
EB> Servlet implementations, they are not the only ones. Stuart, where do
EB> you come by your assertion that browsers are not going to implement
EB> HTTP/2 over upgrade?
EB>

SD> So looks like I mis-remembered, Chrome and Firefox will not
SD> implement h2c, while IE will (although AFAIK have not as yet)

SD> Chrome:
SD> http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0676.html
SD> Firefox (I can't find the email where the definitively state that,
SD> but it is referenced in passing in a lot of the WG emails):
SD> http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0987.html

I have it straight from mcmanus on #necko on irc.mozilla.org:

<mcmanus> right. its 2015 now - all new transports will provide
<mcmanus> encryption as best practice.

SD> IE:
SD> http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0662.html

SD> For what its worth I think we should support h2c in servlet, both
SD> via upgrade and prior knowledge.

>>>>> On Wed, 31 Dec 2014 17:41:04 +0100, Greg Wilkins <gregw_at_intalio.com> said:

GW> Isn't h2c an implementation detail?

[...]

GW> But I don't see how this affects the servlet container API?

>>>>> On Wed, 31 Dec 2014 19:50:10 +0000, Mark Thomas <markt_at_apache.org> said:

MT> I don't think it affects the API. It is more a question of how specific
MT> the Servlet specification wants to be.

MT> Do we leave implementation of h2c as optional for containers or do we
MT> mandate it? I have no strong views at this point.

Well, we have the opportunity to nudge the world a little bit forward
here by explicitly saying h2c is optional. I would like to resolve that
we say h2c is optional. This is a change from my stated position on
2014-12-17.

SECTION: Help with ALPN support

>>>>> On Wed, 17 Dec 2014 09:33:34 +1100, Stuart Douglas <sdouglas_at_redhat.com> said:

EB> Such missed opportunities are the breeding ground for useful FOSS, such
EB> as the work on ALPN in Jetty. I know that's cold comfort for the Tomcat
EB> community, but perhaps Apache HTTPClient cold add support for ALPN?

GW> Our ALPN extension is open sourced and available for other container to
GW> use and I know that some are doing so and have even contributed some
GW> pull requests. https://github.com/jetty-project/jetty-alpn

SD> This is the route we have taken. Its not a great solution though because
SD> the version of the jar you need is different for each JDK.

SD> This would be much easier if it was just part of the JDK.

EB> No doubt, it would be easier.

I have taken the matter to the authorities here at Oracle and I am told
that there will be no standard API in JDK 8 that will help with ALPN.

It is possible that Oracle could provide help with ALPN with some
reusable API in GlassFish. If there is strong interest in that, please
let me know and I'll take up that thread.

SECTION: SE8 support for Servlet 4.0

SD> - Is SE8 support required for compliance?

EB> The current plan of record has Java SE 8 as the minimum JDK level for
EB> Java EE 8.



-- 
| edward.burns_at_oracle.com | office: +1 407 458 0017
| 41 days til DevNexus 2015
| 51 days til JavaLand 2015
| 61 days til CONFESS 2015