A middleware reads its own settings from [middleware.<name>]

[jwrosewell]

Summary

• A middleware reads its own settings from [middleware.].
• Row 38 of the stack in Pluggable, competition-neutral modules with a technical permission model #777, on feature/37-origin-redirect. Mirrors the fork's pull request A middleware reads its own settings from [middleware.<name>] jwrosewell/trusted-server#33, where it was reviewed.

Changes

Area	Change
crates/trusted-server-core/src	2 files, 350 lines added, 4 removed
docs/guide	1 file, 27 lines added, 2 removed
CHANGELOG.md	1 file, 1 line added, 0 removed

Closes

Closes #1331

Test plan

CI: 19 of 19 checks green, the fork's CI on f18d248 (jwrosewell#33).

• cargo test-fastly && cargo test-axum
• cargo clippy-fastly && cargo clippy-axum
• cargo fmt --all -- --check
• JS tests: cd crates/trusted-server-js/lib && npx vitest run
• JS format: cd crates/trusted-server-js/lib && npm run format
• Docs format: cd docs && npm run format
• WASM build: cargo build --package trusted-server-adapter-fastly --release --target wasm32-wasip1
• Manual testing via fastly compute serve
• Other: the full workflow set of this repository, run on the pull request named above

Checklist

• Changes follow AGENTS.md conventions
• No unwrap() in production code (clippy denies unwrap_used in CI)
• Uses log macros as AGENTS.md asks (not println!)
• New code has tests
• No secrets or credentials committed

---

On top of the origin's redirect to itself kept on the reader's address (#32). Issue: #1331.

What this adds

What changes.

A middleware with settings of its own reads them from [middleware.<name>], one table for each middleware, written with the middleware's full name.

[middleware.example.cleanup]
selectors = [".promo", "#newsletter"]

How it works.

• One table per middleware, by its full name. [middleware.example.cleanup] is the example.cleanup middleware's table. A table holds values and arrays. A table within one is the table of the longer name it spells and never a setting, so [middleware.example.cleanup] beneath [middleware.example] belongs to example.cleanup and the example middleware never sees it.
• Core reads none of a table. A middleware reads its own through Settings::middleware_config, which refuses a key the middleware does not know and a value that fails its validation, naming the table.
• Refused at startup. A value under [middleware] where only tables stand, a table at a name no middleware could have, and a table at a name that no module the deployment runs supplies, with the names that could be written, as an entry naming such a middleware is refused today.
• Nothing changes for a middleware without a table. A module's one middleware keeps reading the module's own table, as the stock modules do.

Why

A module's one middleware could read the module's table, and nothing else had a place. A vendor whose module supplies several middleware had to put their settings under the vendor's shared table, where the options of one page change sat beside the vendor's endpoint and license key, which is where nothing about one middleware belongs. A table of each middleware's own keeps a vendor's shared table to what every module of the vendor shares, and keeps every table refusing what it does not know.

What breaks

Nothing. A document without [middleware] reads as before, and no stock module reads the section.

The commits

Commit	What it does
COMMIT_ID	The section, the reader, the startup refusals, the fixture and the guide

CI being read on HEAD_ID.

What is not in this pull request

• A stock module's middleware moving to a table of its own. Each keeps reading its module's table.
• A vendor's middleware that read the vendor's shared table moving to its own, which that vendor's crates do.