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