You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2015/05/13 22:57:52 UTC
HTTP/2 progress report
Just a quick overview to save folks digging through the commit messages.
If you want to play with this you'll need:
- APR + tc-native build from *trunk* (to get ALPN support).
- an EC based cert or set the FireFox option
network.http.spdy.enforce-tls-profile to false
I've been testing with FireFox 38.0 and the examples application.
To see what is going on, enable debug logging for the
org.apache.coyote.http2 package.
With the current code:
- the connection prefaces are sent / received and processed
- additional settings frames are processed
- priority frames are processed
- header frames are partially processed (the decoded headers and values
are logged)
In terms of what this means for a basic working HTTP/2 implementation
(i.e. one that works with simple requests but breaks for anything
remotely close to an edge case)
- You can see the initial connection set-up
- You can see the initial streams set up (to create a dependency
hierarchy with priorities to manage relative priorities of subsequent
requests)
- You can see the initial request
- And then the connection fails.
The HPACK decoder is working (thanks to Stuart Douglas and remm - that
made today a lot more productive).
The next steps are to get a basic implementation working which means:
- figure out how to feed requests into Tomcat's processing chain
- figure out how to extract the response back into the HTTP/2
implementation.
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
Posted by Rémy Maucherat <re...@apache.org>.
2015-05-29 11:13 GMT+02:00 Mark Thomas <ma...@apache.org>:
> On 15/05/2015 19:46, Rémy Maucherat wrote:
> > 2015-05-13 22:57 GMT+02:00 Mark Thomas <ma...@apache.org>:
>
> <snip/>
>
> >> The next steps are to get a basic implementation working which means:
> >> - figure out how to feed requests into Tomcat's processing chain
> >> - figure out how to extract the response back into the HTTP/2
> >> implementation.
> >
> > Is it really a good idea to use the same API for HTTP/2 servlets ? I
> > haven't seen anything going on in the expert group.
>
> The little discussion there has been has been around using a
> RequestDispatcher to trigger server push. There is a strong implication
> there that the existing API will be extended rather than a new one
> added. Based on the general Java EE views on backwards compatibility I'm
> expecting HTTP/2 to have to work (at some level) with existing Servlets.
> What the extended API will look like for HTTP/2 is TBD at this point.
>
Ok, well, as far as I am concerned that's a mistake, it should have an
async IO API on top to make the most out of it. I'll follow the discussions
obviously.
I'm not very convinced about server push either ... One of the features
that could be not so useful in practice.
>
> I have now plumbed in basic request/response processing.
>
> Kudos to those behind the Tomcat 4.1.x refactoring. It was a long time
> ago (before my time on the project) but the API put in place then made
> it incredibly easy to plumb the HTTP/2 stuff into the existing code.
>
Thanks, at least it still works well enough :)
>
> There are still plenty of TODOs (flow control is ignored for request
> bodies for example) but you should be able to navigate around the
> examples app. Note: the async examples don't work (as expected - I
> haven't looked at that yet).
>
> The next steps are:
> - implement the state machine for streams;
> - start thinking about how/when to clean up closed streams;
> - address the various TODOs throughout the code (ignored frame types,
> error conditions, etc);
> - implement the various restrictions required by the spec that
> we currently ignore and just hope the client does the right thing.
> - add async / non-blocking I/O support
>
> Ok !
Rémy
Re: HTTP/2 progress report
Posted by Mark Thomas <ma...@apache.org>.
On 29/05/2015 10:20, Rainer Jung wrote:
> Am 29.05.2015 um 11:13 schrieb Mark Thomas:
>> On 15/05/2015 19:46, Rémy Maucherat wrote:
>>> 2015-05-13 22:57 GMT+02:00 Mark Thomas <ma...@apache.org>:
>>
>> <snip/>
>>
>>>> The next steps are to get a basic implementation working which means:
>>>> - figure out how to feed requests into Tomcat's processing chain
>>>> - figure out how to extract the response back into the HTTP/2
>>>> implementation.
>>>
>>> Is it really a good idea to use the same API for HTTP/2 servlets ? I
>>> haven't seen anything going on in the expert group.
>>
>> The little discussion there has been has been around using a
>> RequestDispatcher to trigger server push. There is a strong implication
>> there that the existing API will be extended rather than a new one
>> added. Based on the general Java EE views on backwards compatibility I'm
>> expecting HTTP/2 to have to work (at some level) with existing Servlets.
>> What the extended API will look like for HTTP/2 is TBD at this point.
>>
>> I have now plumbed in basic request/response processing.
>
> Just a remark on what I have taken from some discussion elsewhere on
> server push: the original idea for server push in HTTP/2 was being able
> to send related content immediately without waiting for the client to
> request it, e.g. JS, CSS, images accompanying a page and similar stuff.
>
> The HTTP/2 server mechanism has no defined way to check, whether a
> client would actually request it or already has it in some cache or
> whether his request would have been served by a cache in between. It is
> all up to servers to create heuristics about when they think server push
> makes sense or not.
>
> Even if there were an API for a webapp to request server push, the
> webapp would face the same heuristics problem.
>
> There might be other easier to solve use cases for HTTP/2 server push,
> but that was the one I saw discussion about. It is definitely not the
> kind of push we see in other APIs or protocols. The HTTP/2 push is
> always triggered by a client request.
>
> Hoping what I wrote makes sense ...
It does. I've seen similar discussions as $work.
I can think of some examples for non-cacheable content where the server
will know that the client will need the resource and can sensibly start
a push but those look to be the exception rather than the rule at this
point.
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
Posted by Rainer Jung <ra...@kippdata.de>.
Am 29.05.2015 um 11:13 schrieb Mark Thomas:
> On 15/05/2015 19:46, Rémy Maucherat wrote:
>> 2015-05-13 22:57 GMT+02:00 Mark Thomas <ma...@apache.org>:
>
> <snip/>
>
>>> The next steps are to get a basic implementation working which means:
>>> - figure out how to feed requests into Tomcat's processing chain
>>> - figure out how to extract the response back into the HTTP/2
>>> implementation.
>>
>> Is it really a good idea to use the same API for HTTP/2 servlets ? I
>> haven't seen anything going on in the expert group.
>
> The little discussion there has been has been around using a
> RequestDispatcher to trigger server push. There is a strong implication
> there that the existing API will be extended rather than a new one
> added. Based on the general Java EE views on backwards compatibility I'm
> expecting HTTP/2 to have to work (at some level) with existing Servlets.
> What the extended API will look like for HTTP/2 is TBD at this point.
>
> I have now plumbed in basic request/response processing.
Just a remark on what I have taken from some discussion elsewhere on
server push: the original idea for server push in HTTP/2 was being able
to send related content immediately without waiting for the client to
request it, e.g. JS, CSS, images accompanying a page and similar stuff.
The HTTP/2 server mechanism has no defined way to check, whether a
client would actually request it or already has it in some cache or
whether his request would have been served by a cache in between. It is
all up to servers to create heuristics about when they think server push
makes sense or not.
Even if there were an API for a webapp to request server push, the
webapp would face the same heuristics problem.
There might be other easier to solve use cases for HTTP/2 server push,
but that was the one I saw discussion about. It is definitely not the
kind of push we see in other APIs or protocols. The HTTP/2 push is
always triggered by a client request.
Hoping what I wrote makes sense ...
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: HTTP/2 progress report
Posted by Mark Thomas <ma...@apache.org>.
On 15/05/2015 19:46, Rémy Maucherat wrote:
> 2015-05-13 22:57 GMT+02:00 Mark Thomas <ma...@apache.org>:
<snip/>
>> The next steps are to get a basic implementation working which means:
>> - figure out how to feed requests into Tomcat's processing chain
>> - figure out how to extract the response back into the HTTP/2
>> implementation.
>
> Is it really a good idea to use the same API for HTTP/2 servlets ? I
> haven't seen anything going on in the expert group.
The little discussion there has been has been around using a
RequestDispatcher to trigger server push. There is a strong implication
there that the existing API will be extended rather than a new one
added. Based on the general Java EE views on backwards compatibility I'm
expecting HTTP/2 to have to work (at some level) with existing Servlets.
What the extended API will look like for HTTP/2 is TBD at this point.
I have now plumbed in basic request/response processing.
Kudos to those behind the Tomcat 4.1.x refactoring. It was a long time
ago (before my time on the project) but the API put in place then made
it incredibly easy to plumb the HTTP/2 stuff into the existing code.
There are still plenty of TODOs (flow control is ignored for request
bodies for example) but you should be able to navigate around the
examples app. Note: the async examples don't work (as expected - I
haven't looked at that yet).
The next steps are:
- implement the state machine for streams;
- start thinking about how/when to clean up closed streams;
- address the various TODOs throughout the code (ignored frame types,
error conditions, etc);
- implement the various restrictions required by the spec that
we currently ignore and just hope the client does the right thing.
- add async / non-blocking I/O support
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
Posted by Rémy Maucherat <re...@apache.org>.
2015-05-13 22:57 GMT+02:00 Mark Thomas <ma...@apache.org>:
> Just a quick overview to save folks digging through the commit messages.
>
> If you want to play with this you'll need:
> - APR + tc-native build from *trunk* (to get ALPN support).
> - an EC based cert or set the FireFox option
> network.http.spdy.enforce-tls-profile to false
>
> I've been testing with FireFox 38.0 and the examples application.
>
> To see what is going on, enable debug logging for the
> org.apache.coyote.http2 package.
>
> With the current code:
> - the connection prefaces are sent / received and processed
> - additional settings frames are processed
> - priority frames are processed
> - header frames are partially processed (the decoded headers and values
> are logged)
>
> In terms of what this means for a basic working HTTP/2 implementation
> (i.e. one that works with simple requests but breaks for anything
> remotely close to an edge case)
> - You can see the initial connection set-up
> - You can see the initial streams set up (to create a dependency
> hierarchy with priorities to manage relative priorities of subsequent
> requests)
> - You can see the initial request
> - And then the connection fails.
>
> The HPACK decoder is working (thanks to Stuart Douglas and remm - that
> made today a lot more productive).
>
Very good overall progress. From my testing the decoder/encoder appeared to
be working very well, and uses the Tomcat structures so it is supposed to
be usable as is. Obviously if there's anything to fix there, I'll have to
contribute it back.
>
> The next steps are to get a basic implementation working which means:
> - figure out how to feed requests into Tomcat's processing chain
> - figure out how to extract the response back into the HTTP/2
> implementation.
>
> Is it really a good idea to use the same API for HTTP/2 servlets ? I
haven't seen anything going on in the expert group.
Rémy