2015-04-08 23:56 GMT+02:00 Mark Thomas <ma...@apache.org>: > As of r1672190 we now have the following: > > - ALPN support in tc-native trunk > - The ability to register upgrade protocol implementations that will: > - be included in the ALPN negotiation > - cause processing to be passed to a protocol dedicated processor > implementation once ALPN negotiation completes > > I have tested this with h2 and it works - up until the point where > processing passes to the HTTP/2 processor. Since that processor is only > a dummy implementation the connection dies at that point. > > This is intended to be extensible. If, for example, WebSocket is added > to the IANA registry for ALPN (I'm not sure if it will be or not) then > it should be relatively simple to add the plumbing to Tomcat to make > that work. > > I'm still thinking where about in the processing chain to insert the > check for HTTP upgrade. It could be as early as the Adapter or as late > as the ContextContextValve. > > I have been considering refactoring WebSocket to use this new HTTP > upgrade process - whatever it becomes - but I think - on balance - it > makes sense not to. They are fundamentally different. > - HTTP upgrade for h2c happens irrespective of the URL being requested. > - HTTP upgrade for WebSocket only happens if the upgrade request is for > a valid URL. > > Given this, I am leaning towards the new HTTP upgrade mechanism (the one > that will be used by h2c) being earlier rather than later in the > processing chain. > > Next steps are: > - start to flesh out the Http2Processor implementation > - provide a 1.2.0-dev build of tc-native for Windows (assuming folks > want one and can't built it themselves) > > Very nice.
As for the user API, it's a big question at the moment. Rémy
