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

[Guillaume Drouet <guidrouet@xxxxxxxxx>]

You're right. Actually we need to parse the resources contents on server-side like the browser does to discover all resources. This is what I try to do with my open source project (https://github.com/wuic/wuic). It already collects all resources referenced by HTML (css, js, images), CSS (images, css, sourcemaps) and _javascript_ (templateUrl in angular apps, sourcemaps). So with a solution like WUIC, we can create a filter that relies on the framework to analyze an HTML page and then push all resources with PushBuilder. Analyzing takes time so if we want to satisfy the first request, the framework must be configured to do the job at build time or when the server starts.

Moreover, an interesting thing is that resources like sourcemaps should have low download priority contrary to other types of resources.

2015-03-31 12:32 GMT+02:00 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="" />

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.
_______________________________________________
jetty-dev mailing list
jetty-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev

--

Guillaume DROUET