(Adjusting subject)
>>>>> 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.
No doubt, it would be easier.
>>>>> 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
>>>>> On Wed, 17 Dec 2014 08:41:21 +0000, Mark Thomas <markt_at_apache.org> said:
MT> No answer, but more questions I am afraid.
MT> Same question as Stuart's above, but asking it separately for h2 and h2c.
The current plan of record is that HTTP/2 support is mandatory for
Servlet 4.0. This means h2 and h2c.
SD> - Is SE8 support required for compliance?
The current plan of record has Java SE 8 as the minimum JDK level for
Java EE 8.
SD> If that is the case you basically have a situation where you can't
SD> actually be compliant unless you modify the JVM's boot class path (I
SD> guess you could support HTTP2 over upgrade, but afaik most browsers are
SD> not planning to implement this).
MT> Given that, do we want to require containers to support h2c?
While browsers do represent the bulk of software interacting with
Servlet implementations, they are not the only ones. Stuart, where do
you come by your assertion that browsers are not going to implement
HTTP/2 over upgrade?
SD> Otherwise you basically have a situation where you can't have a
SD> compliant EE8 container with HTTP2 running on a stock SE8 JVM that
SD> has not had its boot class path modified.
Such classpath modifications are not uncommon for Java EE containers, I
think such a requirement could be accomodated even in the TCK.
>>>>> On Wed, 17 Dec 2014 13:03:58 +0900, Eugene Chung() <euigeun_chung_at_tmax.co.kr> said:
EC> I've been thinking about real-life usages, but I've missed the point
EC> that you addressed. In this circumstance, making TCK test cases for
EC> 'h2' (HTTP/2 over TLS) on Java SE 8 could be also a problem.
I continue to view the matter of ALPN as an implementation detail.
Admittedly a big implementation detail, but still an implementation
detail. We are discussing here what can be done to make that
implementation detail easier for vendors to accept.
This is a matter of convenience. I suspect that vendors that already
have their own ALPN implementation are not worried about viewing it as
an implementation detail. That's not to say I'm writing this whole
discussion off. I'm not, but I do want to keep the issue in
perspective.
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| 48 days til DevNexus 2015
| 58 days til JavaLand 2015
| 68 days til CONFESS 2015