Servlet 4.0: Making More Faster. Server push

Original author: Alex Theedom
  • Transfer
All good and gradually coming!

There is not much time left until the end of this year, but we still seem to have time to launch two courses, one of which will be a course on Java EE. So keep the first part of notes on Servlet 4.0 The

new major release of the Servlet API covers the HTTP / 2 protocol and predicts resource requirements.

The long-awaited update for Java EE 8 includes updates to existing APIs: JAX-RS 2.1, Bean Validation 2.0, JavaServer Faces (JSF) 2.3, Contexts and Dependency Injection (CDI) 2.0, JSON with Padding (JSONP) 1.1 and Servlet 4.0, and There are also two new APIs: JSON-Binding (JSON-B) and Java EE Security. Among these APIs, Servlet 4.0 is a fairly large update, the first since 2009.

The impetus that triggered this big release (rather than a point update) is the global deployment of the HTTP / 2 protocol and the many new features it brings. This HTTP update is the first in nearly 20 years and addresses many of the shortcomings of HTTP 1.x. The new features are numerous (request / response multiplexing, header compression, stream prioritization, and push server), but the most prominent feature for Servlet API users is Server Push, which I will discuss in this article.

Server Push is not the only remarkable addition to Servlet 4.0. This release also introduces enhancements in the form of the Servlet Mapping API, which supports runtime URL recognition, due to improvements in link paths. This article discusses these features, and how Server Push was integrated into the JavaServer Faces 2.3 API.


Server Push

Designed to predict the resources needed on a web page, the Server Push function pushes images, CSS, JavaScript files, and other resources for the client before the request is processed. Therefore, by the time the browser receives a response to its request for a web page, the resources it needs are already in the cache and ready for use.

There is no need to split resources into domains in order to bypass the limitations of browser TCP connections. Just specify the resources and let the server handle the delivery. This is a way that should have existed from the very beginning.

With resources already in the browser cache, the browser can render the page much faster. With a typical web page requiring more than a hundred sourcesIt's easy to see what prospects this presents for increased productivity.

Server Push in Action

Servlets is the underlying technology that underpins Java EE web applications. They provide server capabilities that form the basis of many frameworks. JavaServer Faces (JSF) relies on FacesServlet to manage the request processing life cycle for web applications, and JSP pages are translated into servlets at the first request of the client; therefore, it is not surprising that servlets are the natural place to implement the HTTP / 2 Server Push abstraction.

This abstraction is represented as an object PushBuilder and is created by calling the method newPushBuilder()from the HttpServletRequest request instance passed to all overridden request processing methods.

Using instancePushBuilder you can start pushing the resources required by the requested webpage. The resource is installed on the instance PushBuilder, passing its location to the path () method. The resource is delivered to the client by calling the push () method. It can be reused to send the required amount of resources.

Listing 1 and 2 show the simplest examples of Server Push. Listing 1 shows the servlet that responds to a GET request on a URI / simplestexample:

Listing 1

@WebServlet(“/simplestexample”)
public class SimplestExample extends HttpServlet { 
   @override 
   protected void doGet(HttpServletRequest request,
      HttpServletResponse response)
      throws ServletException, IOException {
      request.newPushBuilder()
         .path("images/coffee-cup.jpg")
         .push();
      getServletContext()
         .getRequestDispatcher("/coffee-cup.jsp") .forward(request, response); }}


Listing 2 shows the JSP web page:

Listing 2

Coffee-Cup


Listing 1 has a servlet called SimplestExampleJSP that the servlet is redirected to. As you can see, only one resource is required on the JSP page - the image coffee-cup.jpg. When the request processing method is called doGet(), it creates a new PushBuilder instance, sets the image location, and calls the push () method to send the resource to the client.

While the image is being sent to the client, the servlet sends a request to the JSP, which requires a coffee-cup.jpg resource. By the time the browser receives the processed HTML, it already has an image in its cache and can display the page without having to make another request.

To see the server’s action in action, you can use the developer tools provided by Google’s Chrome browser. Choose Advanced Tools> Developer Tools, and then go to the Network tab and send a request to the servlet SimplestExample. You should see a result similar to that shown in Figure 1. You can clearly see that the protocol used is h2 (short for “HTTP / 2”), and the image was triggered using Push. This confirms that Server Push was used to satisfy the resource request.


Figure 1: Resource Request Satisfied by Server Push

TLS Required for HTTP / 2

In Figure 1, you may notice that the request scheme is HTTPS. This is due to the fact that all major browser providers have chosen to implement the HTTP / 2 protocol only through Transport Layer Security (TLS). However, the specification does not guarantee that a secure connection is required for a successful HTTP / 2 connection. Browser vendors made this decision on our behalf.

Care must be taken when using the new facility PushBuilder. The call newPushBuilder()will return null if the connection is unsafe, if the client does not support Server Push, or if the client asked to disconnect Server Push through the SETTINGS_ENABLE_PUSH parameter of the SETTINGS section.

If you want to try this example for yourself, you can copy the code from the GitHub repository .

Anatomy of PushBuilder

Each new instance PushBuildercreated during a call newPushBuilder()is based on the current instance HttpServletRequest. It is initiated using the HTTP GET method, and all headers are deleted, with the exception of conditional, range, expect, authorization, and referrer headers.

PushBuilderimplements a template Builderin which a chain of method calls is used to change the properties of an instance before calling a method push(). The resource path is the only configuration required before submitting. The action push initiates an asynchronous non-blocking request, and when it returns, conditional headers and path headers are cleared in preparation for reusing the instance Builder.

You might be wondering how useful it is to usePushBuilderthis way in a real application, and that’s a seasoned question. The example was a bit artificial and is for demonstration purposes only. A more likely scenario is that your application will use JSF or JSP. So, let's take a look at JSF integration and how you can use Server Push with JSP.

The seamless integration of Server Push into the JSF API is especially appreciated, which allows you to use HTTP / 2 features that increase performance without any code changes.

THE END

As always welcome questions, comments that can be asked here or to us at the Open Day.

Also popular now: