fix(web): docs locale middleware serves a language refused with q=0 — localeFromAcceptLanguage has no refusal or malformed-q handling (#1309's unfixed sibling) #1316

Problem

The docs site's locale middleware serves a language the client explicitly refused with q=0, and a malformed q value poisons its sort — the exact bug class fixed for the console in #1309, in a second, unfixed copy of the same Accept-Language parsing logic.

Evidence (main 07eab62f38)

packages/web/src/middleware.ts, localeFromAcceptLanguage (lines 52–84):

• Line 66: q: q ? Number.parseFloat(q) : 1 — no finiteness check, so q=abc becomes NaN and the comparator at line 73 (b.q - a.q) returns NaN, which sort treats as 0: the refused/malformed entry keeps its original position instead of sorting last.
• Lines 76–80: the parsed items are mapped to locales and the first match is returned — there is no refusal skip, so an entry with an explicit finite q=0 (or q=0.0, or negative) is still served if it is the first matching locale.
• Lines 86–97 (onRequest): the result drives a real user-visible redirect — a /docs or /docs/ request is 302-redirected to /docs/<locale>/ (with an oc_locale cookie) based on this function.

The console's copy was fixed in #1309 (PR #1312, merged): packages/console/app/src/lib/language.ts detectFromAcceptLanguage (lines 267–303) now treats a malformed q as 0-weight last-resort and an explicit finite q<=0 as a refusal that is never served. The web middleware copy predates / escaped that fix.

Reproduction (laptop probe, this run)

Probe ~/git/fleet/probe-2026-11-01-web-accept-language/probe.ts on the laptop runs the middleware's function verbatim (with matchLocale stubbed to the real mapping in packages/web/src/i18n/locales.ts for the tested tags):

No test covers this function: packages/web has src/i18n/locales.test.ts, src/lib/share-data.test.ts, and src/pages/s/_share-model-param.test.ts, but nothing for the middleware's Accept-Language handling, and localeFromAcceptLanguage is not exported.

Why it matters

q=0 in Accept-Language means "not acceptable" (RFC 9110 §12.4.2). A user (or a crawler / privacy tool) that explicitly refuses a language is nonetheless redirected into that language's docs and handed a one-year oc_locale cookie pinning the refused choice. Browsers rarely send q=0 for their top language, which is why this survives unnoticed — but the console copy was judged worth fixing in #1309, and the two copies disagreeing means the docs site's behavior depends on which surface a visitor hits.

Acceptance criteria

• An explicit finite q<=0 language is never served by localeFromAcceptLanguage: parsing falls through to the next accepted language, or to root (no redirect) when none is accepted.
• A malformed q value is treated as a 0-weight last-resort offer (mirroring fix(console): detectFromAcceptLanguage serves a language the client explicitly refused with q=0 #1309's pinned console semantics), never as NaN in the sort comparator.
• Normal headers behave exactly as before (controls: bare language defaults to q=1; higher-q accepted language wins).
• Tests cover the refused, all-refused, malformed-q, and control cases and pass in the packages/web test suite (export the helper or extract it the way packages/web/src/pages/s/_share-model-param.test.ts isolates its logic, if the Astro middleware import blocks direct testing).

Related

• fix(console): detectFromAcceptLanguage serves a language the client explicitly refused with q=0 #1309 — the console fix this mirrors (detectFromAcceptLanguage, packages/console/app/src/lib/language.ts)
• fix(ci): check:numeric-boundaries still misses the console and function packages — client- and upstream-supplied conversions escape the regression net #1302 — malformed-q NaN-poisoning disposition for the console/function packages