server returned partial content without a resumable request

Error message

server returned partial content without a resumable request

What it means

During a download, if the server responds with 206 Partial Content but the request was not a resumable (Range) request — there is no resume state to reconcile — mise clears the partial and retries once without resume. If it still receives a partial body without resumable state, it throws this error because it cannot account for the missing bytes.

Source

Thrown at src/http.rs:1013

                    debug!("range request at offset {offset} was unsatisfied for {total} bytes");
                }
                partial.clear()?;
                if offset > 0 && !restarted_without_resume {
                    restarted_without_resume = true;
                    continue;
                }
                resp.error_for_status_ref()?;
            }

            let (write_offset, total_size, validator, resumable, effective_filename) =
                if resp.status() == StatusCode::PARTIAL_CONTENT {
                    let Some((state, _)) = resume else {
                        partial.clear()?;
                        if !restarted_without_resume {
                            restarted_without_resume = true;
                            continue;
                        }
                        bail!("server returned partial content without a resumable request");
                    };
                    let content_range = resp
                        .headers()
                        .get(CONTENT_RANGE)
                        .and_then(|value| value.to_str().ok())
                        .and_then(parse_content_range);
                    let Some(ParsedContentRange::Bytes { start, end, total }) = content_range
                    else {
                        partial.clear()?;
                        if restarted_without_resume {
                            bail!("server returned an invalid Content-Range response");
                        }
                        restarted_without_resume = true;
                        continue;
                    };
                    let validator = response_validator(resp.headers());
                    let response_length_matches = resp
                        .content_length()

View on GitHub (pinned to afd2eddd3a)

Solutions

Retry the download; if it persists, bypass the proxy/mirror (unset *_MIRROR override, try the official URL directly)
Check intermediary proxies/CDNs that strip Range headers or emit spurious 206 responses and fix or avoid them
Report the server's incorrect 206 behavior to the mirror operator; meanwhile install via a different mirror
Update mise in case a newer version hardened handling of such servers

Example fix

# shell
# before
export MISE_NODE_MIRROR='https://broken-mirror.example.com/node'
# after (use official mirror)
unset MISE_NODE_MIRROR

Defensive patterns

Strategy: retry

Validate before calling

// probe that the mirror honors Range correctly before large installs
let resp = reqwest::Client::new().get(url)
    .header(reqwest::header::RANGE, "bytes=0-0").send().await?;
assert!(resp.status().is_success() || resp.status() == 416, "bad mirror range behavior: {}", resp.status());

Try / catch

match download(url, dest).await {
    Err(e) if e.to_string().contains("partial content without a resumable request") => {
        eprintln!("mirror misbehaving; falling back to official URL");
        download(official_url, dest).await?
    }
    other => other?,
}

Prevention

Avoid mirrors/proxies that strip Range headers or reply 206 spuriously
Retry once on transient proxy faults, then switch mirrors
Keep mise updated for hardened HTTP download handling

When it happens

Trigger: Server returns HTTP 206 Partial Content in response to a non-Range (or non-resumable) request, twice — including after the retry without resume. Also triggered by a buggy proxy/CDN that replies 206 incorrectly.

Common situations: Misbehaving reverse proxy or CDN mangling requests/ranges; server with broken HTTP range support replying 206 unconditionally; an aggressive caching proxy in a corporate network stripping Range headers but still answering 206.

Related errors

AI-assisted analysis of jdx/mise@afd2eddd3a (2026-09-09). Data as JSON: /api/errors/4b1be733b03966ff. Report an issue: GitHub.