Re: [jetty-dev] Improving HTTP/2 server push support

[Simone Bordet <sbordet@xxxxxxxxxxx>]

Hi,

On Tue, Mar 31, 2015 at 10:20 AM, Guillaume Drouet <guidrouet@xxxxxxxxx> wrote:
> Hi,
>
> from this topic
> (http://stackoverflow.com/questions/29342106/jetty-http2-server-push-support/29347477#29347477),
> we discussed about server push support and the filters provided out of the
> box by jetty.
>
> I was curious to know how the filter can push all the resources even for the
> first request. Push informations should be provided by the application.
>
> Many of them rely on extensible frameworks that collect this kind of
> informations (for instance thymeleaf which parse a HTML template). Keeping a
> feature inside a framework is important so we let the developer focus on the
> business logic.
>
> So maybe jetty already provides all we need to implement this kind of
> feature in an adequat framework. Maybe a more convenient option to push
> resources will be the interception of link header as explained on
> stackoverflow topic so we don't need to deal with specific jetty API.
>
> What do you think?

I like the idea of a JSP (or Thymeleaf, or other template engines) or
JSF be able to say what needs to be pushed.

The limitation I see is the following.
Let's imagine that we add to the JSTL a new tag:

<c:link push="true" rel="stylesheet" type="text/css" href="styles.css" />

which generates the correspondent <link>, but hints the container to
push it when the JSP is interpreted.
This will work fine, but it cannot detect if the css has associated
resources (for example, background images) that needs to be pushed as
well.
Jetty's PushCacheFilter, instead, can.

The <c:link> solution is already available using Jetty specific APIs,
in particular via the PushBuilder.
A JSP implementation can interpret <c:link> and use the PushBuilder to
build a push request. The same can be done by Thymeleaf or any other
template engine.
Eventually this will be a Servlet 4.0 API.

I am still dubious about the "Link" header: the application would need
to know all resources beforehand (because headers needs to be known
before sending the content) which sometimes is not possible.

Also, ideally we would like older JSPs to work without being changed
and still benefit from the push mechanism. PushCacheFilter offers
that, while making this explicit in the JSP (a feature that I think
should be there anyway) implies that you have to rewrite your JSP to
be push-aware (e.g. replace all <link> with <c:link>, or <img> with
<c:img> etc.)

What we have done so far is to design an API (PushBuilder) that can be
used programmatically, but then offer "smarter" solutions
(PushCacheFilter) that rely on those APIs.

-- 
Simone Bordet
----
http://cometd.org
http://webtide.com
http://intalio.com
Developer advice, training, services and support
from the Jetty & CometD experts.
Intalio, the modern way to build business applications.