Pure HTTP Tasks - Protocol Support and Features

HTTP Protocol Support

• HTTP/1.1
  A plaintext framing that includes persistent connections (RFC 2616).
• HTTP/2
  Binary-framed protocol that includes header compression, multiplexing multiple requests on the same socket, etc. (RFC 7540, RFC 7541, RFC 7301).
• The WebSocket Protocol
  Full-duplex communication channels over a single TCP connection initiated using HTTP/1.1 (RFC 6455).

More about The HTTP/2 protocol

HTTP/2 is the evolution of the world's most successful application layer protocol, HTTP. It focuses on making more efficient use of network resources. It does not change the fundamentals of HTTP, the semantics.

A very good introduction to HTTP/2 is http2 explained by Daniel Stenberg. But ashort summary:

• HTTP/2 is a binary protocol, as opposed to HTTP 1.1 that is plain text. The latter is meant to be human readable (for example sniffing network traffic) meanwhile the former is not. More info in the official FAQ question.
• h2 is HTTP/2 over TLS (protocol negotiation via ALPN).
• h2c is HTTP/2 over TCP ("cleartext TCP").
  Only cleartext TCP with prior knowledge is supported. See RFC 7540, Starting HTTP/2 with Prior Knowledge for details.
• A frame is the smallest unit of communication within an HTTP/2 connection, consisting of a header and a variable-length sequence of octets structured according to the frame type.
• A stream is a bidirectional flow of frames within the HTTP/2 connection. The correspondent concept in HTTP 1.1 is a request/response message exchange.
• HTTP/2 is able to run multiple streams of data over the same TCP connection, avoiding the classic HTTP 1.1 head of blocking slow request and avoiding to re-instantiate TCP connections for each request/response (KeepAlive patched the problem in HTTP 1.1 but did not fully solve it).

Synchronous/asynchronous Tasks

Both synchronous/blocking tasks and asynchronous task are supported.

Authentication

The following HTTP authenticationa> methods are supported:

• Basic HTTP Authentication Scheme (RFC 7617).
• HTTP Digest Access Authentication (RFC 7616).
• Bearer Token Usage (RFC 6750).

HTTPS

Encrypted HTTP using Transport Layer Security (TLS) is supported using the Java 11 platform?s built-in TLS implementation

• TLSv1, TLS version 1.0 (RFC 2246).
• TLSv1.1, TLS version 1.1 (RFC 4346).
• TLSv1.2, TLS version 1.2 (RFC 5246).
• TLSv1.3, TLS version 1.3 (RFC 8446).

Many Cipher suites are supported. See Java Security Standard Algorithm Names for Ciper Suite names to be used.

Response Content encodings

The following response content encodings are supported:

• gzip
• deflate (RFC 1951).
• brotli (RFC 7932).

Brotli is a modern compression algorithm which can provide even better text compression results than gzip and is supported by latest versions of most browsers and web servers.

Proxies

Both HTTP and Socks proxies are supported.

Multi Part

Multi Part request bodies (RFC 2387) are supported.

WebSocket Extensions

In addition to standard WebSocket support (RFC 6455) the WebSocket tasks honors one extension "permessage-deflate" and four parameters, "client_max_window_bits", "client_no_context_takeover", "server_max_window_bits", and "server_no_context_takeover" as described by RFC 7692. This allows compression of the payload of a message using the deflate algorithm.

By default the HTTP request header: "Sec-WebSocket-Extensions: permessage-deflate" is added to support compression. Minimum outbound WebSocket message size (in bytes) that will be compressed is 1024 bytes.

WebSocket heartbeat ping messages can be sent automatically by specifying the Ping Interval parameter in HttpWebSocketInitTask. Explicit ping messages can be sent with the HttpWebSocketPingTask. Incoming ping messages are always automatically answered with a pong.