clockworklabs/SpacetimeDB · critical

Unknown HTTP version: {:?}

Error message

Unknown HTTP version: {:?}

What it means

Thrown while converting an `http` crate `Version` into the SpacetimeDB bindings' `st_http::Version`: the value matched none of the mapped arms. The match already covers HTTP/0.9 through HTTP/3, which is every variant of the current `http` enum, so this `unreachable!` is a guard against a future `http` release adding a new variant (e.g. HTTP/4) that this mapping predates. If you hit it, your binary mixes an `http` crate whose enum no longer matches the code compiled against it.

Source

Thrown at crates/bindings/src/http.rs:677

    http::Request::from_parts(parts, body)
}

#[cfg(feature = "unstable")]
pub(crate) fn response_into_wire(response: http::Response<Body>) -> (st_http::Response, Bytes) {
    let (parts, body) = response.into_parts();
    let st_response = st_http::Response {
        headers: parts
            .headers
            .into_iter()
            .map(|(k, v)| (k.map(|k| k.as_str().into()), v.as_bytes().into()))
            .collect(),
        version: match parts.version {
            http::Version::HTTP_09 => st_http::Version::Http09,
            http::Version::HTTP_10 => st_http::Version::Http10,
            http::Version::HTTP_11 => st_http::Version::Http11,
            http::Version::HTTP_2 => st_http::Version::Http2,
            http::Version::HTTP_3 => st_http::Version::Http3,
            _ => unreachable!("Unknown HTTP version: {:?}", parts.version),
        },
        code: parts.status.as_u16(),
    };

    // TODO(streaming-http): stop collecting the whole response body here once handler
    // responses can write incrementally to a body sink.
    (st_response, body.into_bytes())
}

/// Represents the body of an HTTP request or response.
pub struct Body {
    inner: BodyInner,
}

impl Body {
    /// Treat the body as a sequence of bytes.
    pub fn into_bytes(self) -> Bytes {
        match self.inner {

View on GitHub (pinned to 6dee26c6ef)

Solutions

  1. Check Cargo.lock for an unexpected `http` upgrade and pin the previous version: `cargo update -p http --precise <old-version>`
  2. Upgrade spacetimedb / spacetimedb-bindings to a release whose mapping covers the new HTTP version
  3. If you maintain this code, replace the wildcard arm with an explicit mapping or a real error instead of `unreachable!`

Example fix

// before
let version = match parts.version {
    http::Version::HTTP_09 => st_http::Version::Http09,
    http::Version::HTTP_10 => st_http::Version::Http10,
    http::Version::HTTP_11 => st_http::Version::Http11,
    http::Version::HTTP_2 => st_http::Version::Http2,
    http::Version::HTTP_3 => st_http::Version::Http3,
    _ => unreachable!("Unknown HTTP version: {:?}", parts.version),
};

// after (fail with an error instead of panicking)
let version = match parts.version {
    http::Version::HTTP_09 => st_http::Version::Http09,
    http::Version::HTTP_10 => st_http::Version::Http10,
    http::Version::HTTP_11 => st_http::Version::Http11,
    http::Version::HTTP_2 => st_http::Version::Http2,
    http::Version::HTTP_3 => st_http::Version::Http3,
    other => return Err(unsupported_http_version(other)),
};
Defensive patterns

Strategy: validation

Validate before calling

# Cargo.toml — keep `http` locked to the version your bindings were built against
[dependencies]
http = "=1.2.0"

Type guard

fn is_supported_http_version(v: http::Version) -> bool {
    matches!(
        v,
        http::Version::HTTP_09
            | http::Version::HTTP_10
            | http::Version::HTTP_11
            | http::Version::HTTP_2
            | http::Version::HTTP_3
    )
}

Try / catch

This is a panic, not a Result. If you call the bindings across an FFI or worker boundary, wrap the conversion in std::panic::catch_unwind and surface a 'rebuild against the current http crate' error instead of crashing the host process.

Prevention

When it happens

Trigger: Any path that turns a parsed `http::Response` into `st_http::Response` (response handling in crates/bindings/src/http.rs) after the `http` dependency was upgraded to a version that added a new `Version` variant; the wildcard arm then panics at runtime on responses carrying that version.

Common situations: A `cargo update` or transitive `http` upgrade in a workspace using older spacetimedb-bindings; partially recompiled workspaces where bindings were not rebuilt against the new `http`; a hypothetical future HTTP version negotiated by a newer stack.

Related errors


AI-assisted analysis of clockworklabs/SpacetimeDB@6dee26c6ef (2026-08-20). Data as JSON: /api/errors/3290078ab7f9fd53. Report an issue: GitHub.