Considered, not adopted

RFC 9875 defines two response headers: Cache-Groups tags a response as belonging to one or more named groups, and Cache-Group-Invalidation declares a group stale. Together they let a server say “these seven URLs are one thing” — something HTTP has never been able to express, since invalidation has always been per-URL.

It is a genuinely good idea, and it is finished: Proposed Standard, published October 2025, with both field names registered permanently at IANA. The problem is that nothing appears to implement it. There is no MDN page and no Browser Compatibility Data key, no Chrome Platform Status entry, and no mention in Cloudflare’s cache documentation or changelog — Cloudflare still purges by proprietary Cache-Tag through its dashboard and API, with no in-band header path. Fastly, Varnish, nginx and Squid show no sign of it either. The one candidate implementation, the Go cache Souin, describes its support against the pre-RFC draft.

So a page today would recommend a header that no cache on any reader’s path would read. That is the opposite of what this spec is for. The standard is not the problem; the deployment is, and that can change quickly.

QUERY is a safe, idempotent HTTP method that carries a request body, filling the long-standing gap between GET (safe and cacheable, but no body) and POST (body, but neither). It is a real addition to the platform, published as a Proposed Standard in June 2026.

It is also a property of an API, not of a website. A site does not become better for a visitor, a crawler, or an agent by supporting QUERY; the sites that need it are the ones exposing a search or filter API, and for them the method is an implementation choice among several reasonable ones. There is nothing here to check from the outside and no outcome to describe in terms of the people using the site.

That is the line this spec draws throughout: HTTP methods are how you build a thing, not what a good website does.

A page on subgrid was written and proposed, then closed unmerged. It is worth recording why, because the argument for it was a good one: subgrid has been Baseline widely available since September 2023, the spec already covers container queries and anchor positioning, and cross-component alignment is a real problem.

The reason it did not land is that subgrid is a way of building a site rather than something a good site does. A layout built with subgrid and the same layout built with flexbox and a few explicit track sizes are indistinguishable to the visitor, the crawler, and the agent. There is no header to check, no element to look for, no behaviour to verify. The benefit is real, but it accrues to the developer.

This is the reference case for every newly-Baseline CSS or JavaScript feature the daily standards scan turns up. Container queries and the Popover API earned pages because each maps to something a visitor experiences — components that adapt to the space they are given; dismissal and focus behaviour users can rely on. Most authoring conveniences do not, however well supported they are.

RFC 10023, published as Informational in July 2026 by SIDN Labs, reserves the underscored node name _for-sale so a domain holder can advertise that the parent domain is available for purchase. A TXT record at _for-sale.example.com carries tag-value pairs — ftxt= for human-readable text, furi= for a contact URI, fval= for an asking price, fcod= for a proprietary code. It needs no protocol change and can sit on a domain that is still in active use.

It is externally checkable, which is the test this spec normally applies to DNS-level conventions, and on that count it passes where an HTTP method or a CSS feature would not. What it does not pass is the question of who it is for. Every other signal we spec — CAA, DNSSEC, DNS-AID — tells a visitor, a resolver or an agent something about the site that is there. This one tells a prospective buyer something about the domain, which is a fact about a commercial transaction happening beside the website rather than a property of the website. A good website is not improved by being for sale.

Adoption is the second problem and currently the simpler one: the RFC documents a proposed convention rather than an established practice, and states no deployments. Both objections would have to fall away together — a registrar ecosystem publishing it, and a reason to describe it as something a site does rather than something its owner does — before this is a page. The narrow-audience objection is the one that would need the better argument.