denoland/deno · error · RangeError
The status provided (${init.status}) is not equal to 101 and
Error message
The status provided (${init.status}) is not equal to 101 and outside the range [200, 599] What it means
initializeAResponse enforces the spec rule that a Response status is either 101 or within [200, 599]; anything else throws RangeError naming the offending value. This runs for new Response(...), Response.json(), and Response.redirect()-family constructors, before any body handling.
Source
Thrown at ext/fetch/23_response.js:518
return resp;
}
/**
* https://fetch.spec.whatwg.org#initialize-a-response
* @param {Response} response
* @param {ResponseInit} init
* @param {{ body: fetchBody.InnerBody, contentType: string | null } | null} bodyWithType
*/
function initializeAResponse(
response,
init,
bodyWithType,
prefix,
context,
) {
// 1.
if ((init.status < 200 || init.status > 599) && init.status != 101) {
throw new RangeError(
`The status provided (${init.status}) is not equal to 101 and outside the range [200, 599]`,
);
}
// 2.
if (
init.statusText &&
RegExpPrototypeExec(REASON_PHRASE_RE, init.statusText) === null
) {
throw new TypeError(
`Invalid status text: "${init.statusText}"`,
);
}
// 3.
response[_response].status = init.status;
// 4.View on GitHub (pinned to 89f33cbef2)
Solutions
- Clamp or validate: use a status in 200-599 (or exactly 101) — for errors use 500
- Check Number.isInteger(status) && ((status >= 200 && status <= 599) || status === 101) before constructing
- Map custom application codes into the body/headers, not the HTTP status field
Example fix
// before
return new Response(body, { status: upstreamCode + 1 }); // could be 600
// after
const status = upstreamCode >= 200 && upstreamCode <= 599 ? upstreamCode : 502;
return new Response(body, { status }); Defensive patterns
Strategy: type-guard
Validate before calling
function sanitizeStatus(status, fallback = 500) {
const n = Number(status);
return Number.isInteger(n) && ((n >= 200 && n <= 599) || n === 101) ? n : fallback;
} Type guard
/** @param {unknown} s */
function isValidResponseStatus(s) {
const n = Number(s);
return Number.isInteger(n) && ((n >= 200 && n <= 599) || n === 101);
} Prevention
- Clamp externally sourced status codes to 200-599 (or 101) before Response construction
- Put application error codes in the body, not the status field
- Add a unit test over the boundaries (101, 199, 200, 599, 600) for response builders
When it happens
Trigger: new Response(body, { status: 199 }), { status: 600 }, { status: 102 }, or a status computed from arithmetic that lands outside the range (e.g. statusCode + 1).
Common situations: Forwarding upstream status codes that were transformed incorrectly, off-by-one math on status codes, mapping internal error codes (e.g. 1200, 7000) directly into Response statuses.
Related errors
- Invalid status text: "${init.statusText}"
- Response with null body status cannot have body
- Invalid redirect status code: ${status}
- Invalid header: length must be 2, but is ${header.length}
- Invalid header name: "${name}"
AI-assisted analysis of denoland/deno@89f33cbef2 (2026-08-16).
Data as JSON: /api/errors/e5433285c32de043.
Report an issue: GitHub.