influxdata/influxdb · error · Error

error decoding gzip stream

Error message

error decoding gzip stream: {0}

What it means

`Error::InvalidGzip` is raised when decoding a gzip-compressed request body fails; the underlying `std::io::Error` from the gzip decoder is embedded in the message. The server streams the body through a gzip decoder when `Content-Encoding: gzip` is declared, and corrupt input aborts that stream.

Solutions

  1. Verify the body actually decodes as gzip before sending (gunzip -t file) and that the header matches the real encoding
  2. Ensure the client compresses the body exactly once and only sets Content-Encoding: gzip when it does
  3. Re-send the payload if it was truncated mid-upload; add checksums/retries for large transfers
  4. Bypass intermediaries that may modify the body and test with a direct curl request

Example fix

// before
headers.set('Content-Encoding', 'gzip');
fetch(url, { method: 'POST', body: rawPayload }); // not actually compressed
// after
import zlib from 'zlib';
headers.set('Content-Encoding', 'gzip');
fetch(url, { method: 'POST', body: zlib.gzipSync(rawPayload) });
Defensive patterns

Strategy: validation

Validate before calling

function isGzip(buf) { return buf[0] === 0x1f && buf[1] === 0x8b; }
if (headers['content-encoding'] === 'gzip' && !isGzip(body)) throw new Error('body is not gzip but header says gzip');

Type guard

function gzipHeaderMatches(body, enc) { return enc !== 'gzip' || isGzip(body); }

Try / catch

try { await sendCompressed(); } catch (e) { if (String(e).includes('decoding gzip')) { await sendUncompressed(); } else throw e; }

Prevention

When it happens

Trigger: Sending a body labelled `Content-Encoding: gzip` that is not valid gzip data — e.g. truncated files, double-compressed payloads, a header saying gzip while the body is raw or brotli, or corruption in transit.

Common situations: Clients that set the gzip header without actually compressing, proxies that decompress but leave the header, partially-uploaded files, or double-compression bugs in producer code.

Understand the failure class

Background: Checksum mismatch errors: "checksum verification failed", "digest mismatch", "expected vs actual checksum" — what they mean and how to fix them — this error's family across 41 libraries.

Related errors


AI-assisted analysis of influxdata/influxdb@06200ef96b (2026-09-19). Data as JSON: /api/errors/705a46803a72033a. Report an issue: GitHub.

Appendix: source

Thrown at influxdb3_server/src/http.rs:228

    /// The specified `Content-Encoding` is not acceptable.
    #[error("unacceptable content-encoding: {0}")]
    InvalidContentEncoding(String),

    /// The specified `Content-Type` is not acceptable.
    #[error("unacceptable content-type, expected: {expected}")]
    InvalidContentType { expected: mime::Mime },

    /// The client disconnected.
    #[error("client disconnected")]
    ClientHangup(Box<dyn std::error::Error + Send + Sync>),

    /// The client sent a request body that exceeds the configured maximum.
    #[error("max request size ({0} bytes) exceeded")]
    RequestSizeExceeded(usize),

    /// Decoding a gzip-compressed stream of data failed.
    #[error("error decoding gzip stream: {0}")]
    InvalidGzip(std::io::Error),

    #[error("invalid mime type ({0})")]
    InvalidMimeType(String),

    /// DatabaseName validation error.
    #[error("error validating database name: {0}")]
    InvalidDatabaseName(#[from] DatabaseNameError),

    /// Failure to decode the provided line protocol.
    #[error("failed to parse line protocol: {0}")]
    ParseLineProtocol(influxdb_line_protocol::Error),

    /// The router is currently servicing the maximum permitted number of
    /// simultaneous requests.
    #[error("this service is overloaded, please try again later")]
    RequestLimit,

View on GitHub (pinned to 06200ef96b)