HTTP/2 progress report

[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)

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: HTTP/2 progress report

[Rémy Maucherat <re...@apache.org>]

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