BT

New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

Ed Burns Discusses HTTP/2 and the Java EE Servlet 4 Specification

| by Daniel Bryant Follow 50 Followers on Mar 30, 2015. Estimated reading time: 3 minutes |

At JavaLand 2015, Ed Burns provided an overview of the Java EE Servlet 4.0 specification (JSR 369), the main focus of which is to introduce HTTP/2 support into the Java EE Platform. HTTP/2 aims to overcome problems with the existing HTTP specification, and new features include request/response multiplexing, binary framing, stream prioritisation, server push and header compression.

Burns, a consulting member of the technical staff at Oracle Inc., began the talk by stating that a typical website loads in over 30 different resources, and the inherent limitations in HTTP/1.1 can slow the delivery of these resources to the browser. The primary issue is ‘head-of-line’ (HOL) blocking, which results from the delivery of the resources in the order they were requested. Modern browsers have attempted to work around this issues using techniques such as opening multiple socket connections, domain sharding and file concatenation.

Burns stated that HTTP/2 is essentially a new transport layer underneath HTTP/1.1, which is implemented at the application layer of the OSI model. The protocol still defines the same request/response model, there are no new methods nor headers, no new usage patterns from the application layer, and no new usage of the URL spec and other lower level specs.

The HTTP/1.1 specification states little about how TCP sockets are to be used, and they can be viewed as a throwaway resource. In contrast, the new HTTP/2 specification suggests that sockets are a scarce resource, and states that only a single TCP connection must be opened per server. A ‘stream’ within HTTP/2 is effectively a channel within a TCP connection, over which messages are sent. A frame is the smallest unit of communication in HTTP/2.

The HTTP/2 specification also includes:

  • Request/response multiplexing - each TCP connection is fully bi-directional
  • Binary framing - HTTP/2 is a binary protocol, which makes makes the framing much easier. Determining the start and end of frames is complicated with a text-based protocol, such as HTTP/1.1. Binary framing also solves the HOL blocking problem
  • Stream prioritisation - each stream has a priority, which can be used to the tell the peer which streams are considered most important
  • Server push - this allows the server to populate the browser’s cache in advance of the browser asking for resources
  • Header compression (known as HPACK) - a compression format for efficiently representing HTTP header fields
  • HTTP/2 upgrade from HTTP/1.1 - including the definition of protocol upgrade with transport layers that are both non secure (using port 80 and HTTP status code 101 ‘Switching Protocols’) and secure (using NPN or ALPN)

Burns discussed that there has been criticism of HTTP/2, as this includes the possibility of HOL blocking occurring in the header frames, no support in Firefox or Chrome of protocol upgrades over an non secure transport layer, the increased carbon footprint for HPACK encoding/decoding, the potential for additional DoS attack vectors due to the large surface area of new software that must be written to implement the HTTP/2 specification, and the fact that HTTP/2 is orthogonal to WebSocket.

The presentation concluded by discussing how the new HTTP/2 specification could possibly be exposed in the Java EE Servlet API. Features that could be supported include request/response multiplexing, stream prioritisation, server push, and upgrade from HTTP/1.1.

Stream prioritisation could be implemented by including a new ‘Priority’ class, and accessor and mutator methods could be added to the existing HttpServletRequest and HttpServletResponse classes. Burns also states that server push could be very useful for frameworks such as JSF, and the ability to push resources to a client for a given URL and headers could be implemented.

The Servlet 4.0 specification will bring HTTP/2 to Java EE, and will be a 100% compliant implementation of the HTTP/2 specification. The supporting Java Specification Request, JSR 369, was formed on September 2014, and the tentative proposed final draft could be Q4 2015, leading to a final release in Q3 2016.

Burns encouraged all interested parties to get involved with the creation of Servlet 4.0 via the Adopt-a-JSR program, reading the Aquarium blog and by visiting the GlassFish Java EE reference implementation application server web page. Additional details of accompanying JSR 369 specification can be found on the Java Community Process (JCP) website. JavaLand is an annual Java conference hosted in Brühl, Germany, and details can be found on the JavaLand event website.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT