HTTP/2 expression of interest: F5

This is F5's expression of interest for HTTP/2.

In the majority of its deployments F5's products sit at the server-end of the protocol (HTTP or other) and relies on features that are implemented by the client (browser). Any HTTP related features (HTTP/2 or other) that receive wide browser support will be considered for support/implementation by F5 for (some of) its products, if believed to add value for our customers.

Because of the wide deployment of SPDY in today's browsers (particularly Chrome and Firefox) and the benefits it brings, F5 has implemented the SPDY protocol. Hence F5 expresses interest in SPDY as starting point for an HTTP/2 proposal.

Here is a summary of my personal experience with SPDY so far...

I see the following benefits of SPDY and some related issues:

-          SPDY's multiplexing scheme is a huge improvement over HTTP (pipelining).

-          SPDY's compression greatly reduces request and response headers (often to fit a single IP frame). Especially on the request side this helps performance.

o   There are some issues with the compression scheme

-          The use of TLS is desirable.

o   But it complicates the deployment of value-adding proxies.

-          The use of TLS NPN reduces the need for additional end-point and/or protocol schemes.

o   There is some confusion around the use of http vs. https, which are hard to understand, even by experienced http users.

Some elaboration on the issues I think need to be addressed in HTTP/2:

-          In the SPDY protocol the client chooses the compression window. The server is forced allocate a buffer the size of the compression window. Today we're forced to allocate 32 Kb per connection for decompression. For a high-end implementation this can end up being a constraining factor. It is desirable for the server to be able control this window size.

-          There are certain type of errors that could be communicated to the client without decompressing the request (e.g. 'server is busy'). Currently the server has to decompress the request (to keep the compression context in sync) or disconnect. The former consumes unneeded resources, the second can cause the browser to fall back to HTTP or restart a SPDY connection (which causes a new TLS handshake, hopefully abbreviated).

-          The use of http and/or https URIs in SPDY is inconsistent and confusing (and even can render SPDY ineffective when applications generate the wrong absolute URIs). The guidelines for browser and server behavior should be part of the spec to assure consistency.

o   During the implementation of a SPDY to HTTP proxy, we found the need for a separate trust relationship with a proxy (one that translates protocols or manipulates payload).

-          The handling of priorities is unspecified and we've experimented with different implementations.

o   It seems that browser implementers could benefit from knowing how the server handles priorities.

-          Though NTLM was/is problematic as an HTTP authentication scheme and seems incompatible with SPDY. However support for connection oriented authentication schemes (maybe PAM based) do seem appropriate for SPDY and would help accelerate request handling (eliminating per request credentials).

This email cannot be interpreted as a promise of F5 to make SPDY (or any other HTTP/2 proposal) available in any version of its products. For inquiries/requests of this nature please contact our Product Management organization.

Jeroen de Borst
Software Engineer, F5 Networks