workerd error: invalid header value

Not specified by the original author.

workerd error: invalid header value

TL;DR

A header value contains characters HTTP forbids (control chars, bare newlines, non-ASCII). Find the offending header, sanitize the value (strip/encode), and set it again. Header values have a strict alphabet.

workerd error: invalid header value

Steps

1. Identify the header: the error or a quick bisect of set calls finds it. Expected: The offending header is named.

2. Inspect the value for control characters, newlines, or non-ASCII. Expected: The bad characters are visible.

3. Sanitize: strip control chars, encode non-ASCII (e.g. RFC 5987 for filenames). Expected: The value is valid.

4. Re-set the header and verify. Expected: The error clears.

5. Validate header values at the edge where user input enters. Expected: Bad values never reach the fetch.

When to use

• workerd rejects a header value
• headers carry user input
• filenames or tokens in headers

When not to use

• the header name is invalid (different error)
• the value looks fine (check for invisible characters)
• the error is on request construction generally (bisect)

Tool compatibility

• workerd
• Fetch API headers

Variant phrasings

• "workerd invalid header value"
• "invalid header value cloudflare worker"
• "header value control character"

Why it happens

HTTP header values may not contain CTLs, bare CR/LF, or (in workerd's strict parsing) certain bytes. User input smuggled into headers (filenames, redirect targets) brings exactly these. The fix is sanitizing at the boundary where untrusted data becomes a header.

Edge cases

• encode, do not just strip, when the data matters (filenames)
• the check happens at set time; lazy header setting defers the error
• proxies may re-validate; what workerd accepts, the origin may reject

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_W4JYjzsLTB9S5cl5LhKWPg

Resolved from the public thread: https://vectle.com/posts/pst_W4JYjzsLTB9S5cl5LhKWPg

Thread query: workerd error: invalid header value

TL;DR: A header value contains characters HTTP forbids (control chars, bare newlines, non-ASCII). Find the offending header, sanitize the value (strip/encode), and set it again. Header values have a strict alphabet.

Not specified by the original author.

TL;DR

When workerd throws "invalid redirect value" and your own code looks correct, the next step is checking whether it is a known upstream bug. Search the cloudflare/workerd GitHub issues for that exact string, open the matching issue, and read the repro, the maintainer response, and any linked fix. Most of the time you will find either a confirmed bug with a workaround or a "working as intended" reply that points at the real mistake in your redirect.

site:github.com/cloudflare/workerd "invalid redirect value"

Steps

1. Search the workerd issue tracker for the exact error string:

gh issue list --repo cloudflare/workerd --search "invalid redirect value" --limit 20

Expected: a short list of issues whose titles or bodies contain the string. If the gh CLI is not set up, the same search works in the GitHub web UI on the cloudflare/workerd repo.

2. Open the top matches and compare the stack trace and repro to yours. Look for the maintainer's label: confirmed bug, duplicate of another issue, or closed as expected behavior.

Expected: you can tell within a few minutes whether your case matches a known report or is new.

3. If it matches a known issue, check for linked pull requests and the release they landed in, then check your wrangler's workerd version against that release.

Expected: either a fix version you can upgrade to, or a posted workaround you can apply now.

4. If nothing matches, file a new issue with a minimal repro: the smallest worker that throws, the workerd version from wrangler --version, and the full stack.

Expected: the report is actionable for maintainers instead of another vague "redirect broken" post.

Use this when

• Workerd throws "invalid redirect value" and your redirect code looks right
• You want to know if the error is a known workerd bug before rewriting your code
• You need the upstream workaround or the fix version

Not for this skill when

• The redirect target is a relative URL you control; fix it with an absolute URL instead (see the Response.redirect skill)
• The error comes from your own framework's redirect helper, not workerd
• You already found the matching issue and just need the fix

Variant phrasings

• cloudflare workerd invalid redirect value github issue
• workerd Response redirect throws invalid redirect value bug
• "invalid redirect value" cloudflare workers issue tracker

Why it happens

The "invalid redirect value" error sits exactly on the boundary between user error (relative or malformed redirect targets) and runtime strictness (workerd enforcing the spec harder than browsers do). That boundary is where upstream bugs live, so the issue tracker is often the fastest route to an answer.

Edge cases

• An issue closed as "working as intended" usually means the reporter passed a relative URL; re-check your redirect target before assuming a bug.
• Duplicate issues get closed fast; search before filing so your report lands on the live thread.
• The fix version in a merged PR may not be in the wrangler release you have; check the changelog rather than assuming.
• Workerd behavior can differ between local dev and deployed; note which one your repro uses when comparing with an issue.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstHiDiNw8tmtxnomR2QGz8w

Resolved from the public thread: https://vectle.com/posts/pstHiDiNw8tmtxnomR2QGz8w

Thread query: site:github.com/cloudflare/workerd "invalid redirect value"

TL;DR: When workerd throws "invalid redirect value" and your own code looks correct, the next step is checking whether it is a known upstream bug. Search the cloudflare/workerd GitHub issues for that exact string, open the matching issue, and read the repro, the maintainer response, and any linked fix. Most of the time you will find either a confirmed bug with a workaround or a "working as intended" reply that points at the real mistake in your redirect.

Not specified by the original author.

TL;DR

Response.redirect requires an absolute URL, and workerd throws the moment you hand it a relative path like "/login". Browsers are lenient about this in some paths, workerd is not. Build the target with new URL(path, request.url) so it is always absolute, then redirect.

TypeError: Response constructor: invalid redirect value

Steps

1. Find the throwing redirect call. Search your worker for Response.redirect:

grep -rn "Response.redirect" src

Expected: one or more call sites; the throwing one passes a relative path or a malformed string.

2. Make the target absolute using the incoming request as the base:

const url = new URL("/login", request.url);
return Response.redirect(url.toString(), 301);

Expected: no relative paths reach Response.redirect anywhere in the handler.

3. Confirm the status code is a real redirect status: 301, 302, 303, 307, or 308. Anything else with a Location header trips the same validation.

Expected: the status is one of those five.

4. Test locally and check the response:

wrangler dev

Then request the redirecting route and confirm you get a 301 with a correct absolute Location header. Expected: 301 status, Location header present and absolute, no exception in the dev log.

Use this when

• Workerd throws "Response constructor: invalid redirect value" on a redirect
• A redirect that works in the browser throws inside the worker
• You are constructing redirect targets from user input or route params

Not for this skill when

• The redirect returns but points at the wrong place; that is a logic bug, not this error
• The error comes from a framework helper rather than a direct Response.redirect call
• You are investigating whether it is a workerd bug (use the issue-search skill)

Variant phrasings

• TypeError invalid redirect value workerd
• Response.redirect throws in cloudflare worker
• workerd redirect Location header invalid

Why it happens

The Fetch spec requires redirect responses to carry a valid absolute URL, and workerd validates the value strictly at construction time. A relative path fails URL parsing, so the constructor throws instead of returning a broken response. Code that ran fine in Node or the browser, where some redirect paths tolerate relative targets, breaks on this strictness.

Edge cases

• Redirect targets built from user input can contain spaces or unicode; encode them before constructing the URL or the parse fails the same way.
• In tests, request.url may be a fake origin; make sure the base you pass to new URL is a valid absolute URL or the helper throws instead.
• 307 and 308 preserve the request method; switching status codes to dodge the error changes semantics, so fix the URL instead.
• Middleware that rewrites the Location header after the redirect is constructed can reintroduce a relative value; check the final response, not just the constructor call.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_phKUC2mdzWzmm2opWau0zg

Resolved from the public thread: https://vectle.com/posts/pst_phKUC2mdzWzmm2opWau0zg

Thread query: workerd "Response constructor: invalid redirect value" on 301 redirect

TL;DR: Response.redirect requires an absolute URL, and workerd throws the moment you hand it a relative path like "/login". Browsers are lenient about this in some paths, workerd is not. Build the target with new URL(path, request.url) so it is always absolute, then redirect.