WebServer HTTP Compression

HTTP compression can improve bandwidth utilization and transfer speeds in certain scenarios. It requires a few extra CPU cycles for compressing and uncompressing, but these can be offset if data is transferred over low-bandwidth network links.

A client advertises the compression encodings it supports at request time, and the WebServer responds by selecting an encoding it supports and setting it in a header, effectively negotiating the content encoding of the response. If none of the advertised encodings is supported by the WebServer, the response is returned uncompressed.

Configuring HTTP Compression

HTTP compression in the Helidon WebServer is disabled by default. It can sometimes interfere with certain applications that use streaming, even if a compression encoding has not been negotiated with the client.

It can be enabled either programmatically or via configuration, and it can also be enabled on a per-socket basis. When configured at the server level, it applies only to the default socket.

Programmatically, simply use the enableCompression method during server creation:

    WebServer.builder()
             .port(8080)
             .routing(...)
             .enableCompression(true)        // compression enabled
             .build()
Copied

Or use a config file as follows and make sure the WebServer is created using it:

WebServer HTTP Compression configuration file application.yaml
server:
  port: 8080
  enable-compression: true
Copied

HTTP Compression Negotiation

HTTP compression negotiation is controlled by clients using the Accept-Encoding header. The value of this header is a comma-separated list of encodings. The WebServer will select one of these encodings for compression purposes; it currently supports gzip and deflate.

For example, if the request includes Accept-Encoding: gzip, deflate, and HTTP compression has been enabled as shown above, the response shall include the header Content-Encoding: gzip and a compressed payload.