Compression

Burl can advertise the content codings it accepts and transparently decode a compressed response body, so gzip, deflate, br, and zstd responses arrive already decompressed. Decoding for each coding is compiled into the library when it is built with the corresponding compression library.

Build Support

The build detects zlib, Brotli, and zstd and enables the codings they provide: zlib handles gzip and deflate, Brotli handles br, and zstd handles zstd. The macros BOOST_BURL_HAS_ZLIB, BOOST_BURL_HAS_BROTLI, and BOOST_BURL_HAS_ZSTD indicate which codings the library was built with.

How It Works

Every supported coding is enabled by default: the client adds it to the Accept-Encoding request header and decodes a response encoded with it. The configuration controls each coding individually.

burl::client::config cfg;
cfg.gzip    = true;
cfg.deflate = true;
cfg.brotli  = false;   // do not advertise or decode br
cfg.zstd    = false;   // do not advertise or decode zstd

burl::client client(co_await capy::this_coro::executor, tls_ctx, cfg);

A coding whose decoder was not compiled into the library is disabled regardless of the setting, since the client cannot honor what it advertises.

The decoding is transparent: the body you read through any of the body functions is the decoded content, and response::content_length and the Content-Length header reflect the encoded size as sent on the wire.

Opting Out for a Request

A request that sets its own Accept-Encoding header is left alone: the client neither adds codings to it nor decodes the response. This is the way to control encoding for a single request:

auto [ec, r] = co_await client.get("https://example.com/data")
    .header(http::field::accept_encoding, "identity")
    .send();

Next Steps

Edit this Page