Correct three log-review filters that produce plausible wrong answers

[ptr727]

Three filters in OPERATIONS.md "Reading a 404 list" produce plausible wrong answers. The host side found two of them and diagnosed the third; all three are verified here against the same day's log before being written down.

The referer rule as committed does not work

It said to compare the referer against scheme://RequestHost + RequestPath. Read literally that matches nothing, because a scanner reaching an HTTPS site routinely sends an http:// referer for the same address.

Form	Survivors on 2026-08-08 site-host 404s
naive, request's own scheme	36, every one a false positive
scheme normalized	0

The implementation that produced the original "zero broken links" happened to test both schemes explicitly, so the number was right and the prose anyone would rebuild from was wrong. That is the worse half: a wrong command in a procedure outlives the session that got the right answer despite it.

RequestHost is null on some requests

Two records that day carry no Host header at all, both router exploits. A bare .RequestHost | startswith(...) then fails with startswith() requires string inputs and takes the run with it, part way through a file that has already printed real output. Loud but partial is the worst shape a failure can take, because the output above the error looks complete.

Defaulted with // "".

ServiceName says the edge answered; entryPointName and RequestScheme say why

The two routerless 404s recorded in the previous change were cleartext HTTP to port 443. The websecure router carries tls and matches TLS requests only, so a plaintext request to 443 matches nothing and traefik answers its own 404. Verified here: both records are websecure + http on one ClientPort with a 19-byte body, and every websecure + http request in the log is routerless.

Correct behavior, needing no action — not the proxy reconfiguration window this repo guessed at, which is now removed rather than left as a plausible-sounding cause. The shape that does deserve investigation is a routerless 404 arriving over https, meaning a hostname the proxy serves no route for.

Verification

The documented filter is now a runnable command rather than a description, and it was run:

• site-host survivors: 0, as the section claims
• the naive form it replaces: 36
• no jq abort on the null-host records

markdownlint, editorconfig-checker and the hub's prose_lint.py are all clean, the last at its exact baseline for this file.

[Copilot]

Pull request overview

Updates the operational log-review procedure in OPERATIONS.md to prevent misleading results when filtering Traefik 404s, based on verified behaviors observed in real traffic.

Changes:

• Clarifies interpretation of routerless 404s by correlating ServiceName with entryPointName and RequestScheme.
• Replaces an ambiguous referer-check description with a concrete jq command that normalizes schemes and handles null RequestHost.
• Documents the failure mode of null RequestHost and why // "" is needed to avoid mid-stream jq aborts.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (2)

OPERATIONS.md:282

• The comment above the jq example says // "" is needed because startswith aborts on a null host, but the example host filter uses an equality check (no startswith). This makes the rationale confusing (and repeats the earlier mismatch you already fixed).

# Narrow to this site's own 404s, then keep only referers pointing somewhere else.
# `// ""` is on the host filter because startswith aborts on a null host; the concatenation
# below needs no guard, since jq treats null + "/path" as "/path".

OPERATIONS.md:267

• The sentence “ServiceName says that the edge answered” reads as the opposite of the rule stated just above (service name present => routed/site answered; field absent => routerless/edge answered). This is likely to mislead readers trying to interpret routerless 404s.

**`ServiceName` says that the edge answered, and `entryPointName` with `RequestScheme` says why**, which is the difference between a finding and a fault. The common cause is a cleartext request to the TLS port: the `websecure` router carries `tls` and therefore matches TLS requests only, so a plaintext request to 443 matches nothing and Traefik answers its own 404 with a body of a few dozen bytes. That is correct behavior rather than a gap, and it needs no action. Read the two fields together before treating a routerless 404 as a routing problem, because the shape that does deserve investigation is a routerless 404 arriving over **https**, which means a hostname the proxy serves no route for.

[ptr727]

Both suppressed findings were real and both are fixed in 50bb469.

---

OPERATIONS.md:282 — The comment above the jq example says // "" is needed because startswith aborts on a null host, but the example host filter uses an equality check (no startswith). This makes the rationale confusing (and repeats the earlier mismatch you already fixed).

Correct, and the parenthesis is the fair part — this is the same mismatch class I had just claimed to fix. Worse on inspection: equality tolerates a null exactly as concatenation does, so // "" was inert in both places it appeared in that example. A guard that guards nothing is worse than no guard, because it stops the next reader from checking.

The example now carries no guard and a comment saying why, with the note that swapping the equality for startswith makes one mandatory. The paragraph below states the rule across all three operators rather than two: string functions reject a null host, equality and concatenation tolerate it.

---

OPERATIONS.md:267 — The sentence "ServiceName says that the edge answered" reads as the opposite of the rule stated just above (service name present => routed/site answered; field absent => routerless/edge answered).

Correct. The sentence leads with the field name where the rule is about its absence, so it inverts the paragraph immediately above it. That is exactly the sentence someone reads while trying to interpret a routerless 404, which is the worst place for it. Rewritten to lead with the absence.

---

Re-verified after the change: the documented example returns zero survivors on the site host, and does not abort on the two records that carry no Host header.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.