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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to