rama::http::headers::sec_websocket_extensions

Struct PerMessageDeflateConfig

pub struct PerMessageDeflateConfig {
    pub identifier: PerMessageDeflateIdentifier,
    pub server_no_context_takeover: bool,
    pub client_no_context_takeover: bool,
    pub server_max_window_bits: Option<u8>,
    pub client_max_window_bits: Option<u8>,
}

Fields§

§identifier: PerMessageDeflateIdentifier

Identifier used (or to be used).

When serializing the default one is to be used if none is specified.

§server_no_context_takeover: bool

Prevents Server Context Takeover

This extension parameter enables a client to request that the server forgo context takeover, thereby eliminating the client’s need to retain memory for the LZ77 sliding window between messages.

A client’s omission of this parameter indicates its capability to decompress messages even if the server utilizes context takeover.

Servers should support this parameter and confirm acceptance by including it in their response; they may even include it if not explicitly requested by the client.

§client_no_context_takeover: bool

Manages Client Context Takeover

This extension parameter allows a client to indicate to the server its intent not to use context takeover, even if the server doesn’t explicitly respond with the same parameter.

When a server receives this, it can either ignore it or include client_no_context_takeover in its response, which prevents the client from using context takeover and helps the server conserve memory. If the server’s response omits this parameter, it signals its ability to decompress messages where the client does use context takeover.

Clients are required to support this parameter in a server’s response.

§server_max_window_bits: Option<u8>

Limits Server Window Size

This extension parameter allows a client to propose a maximum LZ77 sliding window size for the server to use when compressing messages, specified as a base-2 logarithm (8-15).

This helps the client reduce its memory requirements. If a client omits this parameter, it signals its capacity to handle messages compressed with a window up to 32,768 bytes.

A server accepts by echoing the parameter with an equal or smaller value; otherwise, it declines. Notably, a server may suggest a window size even if the client didn’t initially propose one.

§client_max_window_bits: Option<u8>

Adjusts Client Window Size

This extension parameter allows a client to propose, optionally with a value between 8 and 15 (base-2 logarithm), the maximum LZ77 sliding window size it will use for compression.

This signals to the server that the client supports this parameter in responses and, if a value is provided, hints that the client won’t exceed that window size for its own compression, regardless of the server’s response.

A server can then include client_max_window_bits in its response with an equal or smaller value, thereby limiting the client’s window size and reducing its own memory overhead for decompression.

If the server’s response omits this parameter, it signifies its ability to decompress messages compressed with a client window up to 32,768 bytes.

Servers must not include this parameter in their response if the client’s initial offer didn’t contain it.