feat(api)!: select rules by Rule id + the cookie conformance domain

[parkrevil]

Summary

Two things ship together:

• Rule-only selection. ashward(url, [Rule.OriginReflection]) now works. Previously the name you could say (Rule.X) was not the thing you could pass (rules.x, a RuleDef). Breaking: ALL_RULES, ALL_RULE_IDS, the rules.* namespace, and RuleDef/HttpRuleContext/HttpTarget/ProbeFn are removed. Public surface is 9 names.
• Cookie conformance domain. 32 new rules plus a consumer simulator, with the catalog extracted into a shared conformance catalog.

Also: an empty result set no longer passes (ranNothing), and cookieSim is wired to the public options.

Correction. An earlier version of this description claimed ranNothing was widened to "empty or all-skip". That is not implemented — ok-policy.ts:52 is still results.length === 0, and an all-Skip run is still green. The all-Skip widening is designed but unstarted. See review finding 3.

Release

Two pending changesets, both minor → 0.3.0. The selection change is breaking, but the package is 0.x and coverage(), Report.counts and the Severity redesign are still open — 1.0.0 would read as a stability claim it can't back.

Verification

993 pass / 0 fail · coverage 100% line / 99.13% branch (gate 95%) · tsgo --noEmit clean · oxlint --type-aware clean · oxfmt --check clean · build clean. CI verify green. Rebased onto main @ 0.2.0.

Not merge-ready: six correctness findings from review reproduce against this head and are unfixed. See the review thread.

🤖 Generated with Claude Code

[parkrevil]

Review summary

I am requesting changes based on six reproducible correctness issues. I reviewed these against the current PR head (8042fe8), the PR description and commit history, the repository's own rule-ownership conventions, and the current RFC 6265bis editor's draft. I did not modify the branch.

1. Raw Set-Cookie octets are changed by UTF-8 decoding

Affected code: src/http/decode/head-parse.ts:33, src/normative/octet-length.ts:9, src/rules/kit/cookie-sim.ts:86-88,210-218, src/rules/discard-oversize-4096.ts:18-21

parseResponseHead() decodes every field line with the default TextDecoder. Invalid UTF-8 octets become U+FFFD, after which octetLength() UTF-8-encodes the changed string. This alters both lengths and values before the cookie rules inspect them.

Reproduction through the complete rule execution path:

wire Set-Cookie value: "a=" + 1366 × 0xFF
actual name + value length: 1367 octets
discard-oversize-4096 result: Fail

Each 0xFF becomes U+FFFD and is subsequently counted as three UTF-8 octets, so a cookie far below 4096 octets is reported as discarded for exceeding the limit. The same problem affects the 1024-octet attribute limit.

This also changes semantics, not just lengths. With Set-Cookie: a=b; Domain=K (wire bytes E2 84 AA) and target host k, Unicode toLowerCase() maps K to ASCII k; both discard-domain-char and discard-domain-mismatch return Pass. Those original octets are outside CHAR, so the cookie must be discarded at the Domain CHAR step.

RFC 6265bis requires parsing the individual octets without decoding them, and RFC 9110 says obs-text (%x80-FF) is opaque data:

• https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html#section-5.6
• https://www.rfc-editor.org/rfc/rfc9110.html#section-5.5

This contradicts the cookie implementation's stated octet-exact behavior and produces both false Fail and false Pass results.

2. The reduced PSL produces both false Pass and false Fail verdicts

Affected code: src/normative/public-suffix.ts:16-56, src/rules/discard-public-suffix.ts:33-34, src/rules/discard-host-prefix.ts:17-22

The reduced list is deliberate, but its documented claim that omissions are conservative and can never create false Fail results is incorrect. publicSuffixConfigured: true exposes definitive Pass/Fail results while the implementation recognizes only 35 literal suffixes and supports neither wildcard nor exception rules.

Reproduced false Pass:

target host: foo.xyz
Set-Cookie: a=b; Domain=xyz
cookieSim: { publicSuffixConfigured: true }
discard-public-suffix result: Pass
expected: Fail (xyz is an ICANN public suffix)

Reproduced false Fail:

target host: xyz
Set-Cookie: __Host-a=1; Secure; Path=/; Domain=xyz
cookieSim: { publicSuffixConfigured: true }
discard-host-prefix result: Fail
expected: Pass

At RFC 6265bis section 5.7 step 9, a public-suffix Domain identical to the request host is cleared. The cookie therefore becomes host-only and satisfies the __Host- contract. Because xyz is absent from the reduced set, that clearing never occurs. co.uk works as the control case only because it is hard-coded.

Wildcard PSL rules fail similarly (*.ck / !www.ck). Sources:

• https://publicsuffix.org/list/public_suffix_list.dat
• https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html#section-8.9

Thus this is not merely incomplete coverage: the public option can return incorrect conclusions in both directions.

3. The PR claims all-Skip runs are blocked, but they remain green

Affected code: src/core/report/ok-policy.ts:51-52, src/core/assert/assert-ok.ts:18-25

The current PR description states that ranNothing was widened to cover an empty result set or all-Skip results. The accepted follow-up design also distinguishes this from treating individual skips as failures. However, the implementation remains:

return results.length === 0;

Reproduction:

results: [{ verdict: Skip, reason: HeaderAbsent }]
report.ok(): true
assertOk(report): does not throw

The history matters here: commit 8c36639 originally intended to block empty results only, and the existing test still explicitly expects a Skip-only report to be OK. The later all-Skip requirement was designed but not implemented, while the current PR description presents it as shipped. Therefore this is a concrete mismatch between the PR's declared scope and the code, rather than evidence that every individual Skip should fail.

4. Legal HTAB OWS after ; is reported as an invalid cookie attribute

Affected code: src/rules/cookie-av-shape.ts:10-25, src/rules/kit/cookie-grammar.ts:11-27

Reproduction:

Set-Cookie: a=b;\tSecure

Actual results:

cookie-av-shape: Fail
forbidden-wsp: Pass

RFC 6265bis defines this boundary as ";" OWS cookie-av, and RFC 9110 defines OWS as zero or more SP/HTAB octets. rawAvSegments() retains the leading HTAB, and cookie-av-shape then tests it as though it were part of cookie-av; HTAB is not an av-octet, so the valid OWS is falsely reported as a producer grammar violation.

• https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html#section-4.1.1
• https://www.rfc-editor.org/rfc/rfc9110.html#section-5.6.3

The adjacent forbidden-wsp implementation already recognizes leading WSP after ; as legal OWS, confirming the intended ownership at this boundary.

5. Later section 5.7 discard rules fire after an earlier step has already aborted

Affected code: src/rules/discard-samesite-none-insecure.ts:20-34, src/rules/discard-nameless-prefix-value.ts:16-24, src/rules/kit/cookie-sim.ts:276-309, src/rules/discard-secure-prefix.ts:21-30

Several consequence rules report a later discard cause even when the cookie never reaches that RFC step.

Examples reproduced through rule.run():

target: site.example
Set-Cookie: a=b; Domain=other.example; SameSite=None
actual: discard-domain-mismatch Fail + discard-samesite-none-insecure Fail
expected attribution: Domain mismatch only; step 10 aborts before step 19

Set-Cookie: =__Secure-a; SameSite=None
actual: discard-nameless-prefix-value Fail
expected attribution: SameSite=None without Secure aborts at step 19 before step 22

Set-Cookie: __Secure-a=1; SameSite=None
actual: SameSite rule Fail + Secure-prefix rule Fail
expected attribution: step 19 aborts before the prefix step

The final conclusion that the cookie is discarded remains true, but the named rule attribution is false. This is inconsistent with the repository's stated intent: discard-oversize-4096 explicitly excludes cookies aborted by the preceding CTL step, prefix-rule comments say they count only cookies that reach the prefix step, and reachesPrefixStep() was introduced specifically to model earlier Domain/PSL aborts. The gating is only partial.

6. Two different malformed fields are reported as duplicate cookie names

Affected code: src/rules/no-duplicate-name-across-fields.ts:16-19

Reproduction:

Set-Cookie: foo
Set-Cookie: bar

Actual results:

cookie-pair-equals: Fail
no-duplicate-name-across-fields: Fail

Neither field has a section 4.1.1 cookie-pair or cookie-name. The producer duplicate-name rule nevertheless feeds both values through the section 5.6 consumer parser, which maps every equals-less value to name === ""; the two unrelated malformed fields are then treated as duplicate names.

The adjacent producer rules cookie-name-token and cookie-name-nonempty deliberately exclude equals-less fields because cookie-pair-equals owns that malformed shape. The duplicate-name rule should follow the same producer-rule boundary rather than deriving a synthetic empty name from the consumer parser.

Verification

• Existing suite: 993 pass / 0 fail
• tsgo --noEmit: pass
• type-aware lint: pass
• build: pass
• Each finding above was separately reproduced against the current PR head through the relevant rule/report execution path.