# 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.

```text
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