Repository navigation
Read middleware settings from [middleware.<name>] - #1379
Open
jwrosewell wants to merge 38 commits into
Open
jwrosewell wants to merge 38 commits into
jwrosewell wants to merge 38 commits into
Conversation
A middleware had no table of its own. A module's one middleware read the module's table, and a vendor whose module supplies several middleware put their settings under the vendor's shared table, where a page change's options sat beside the vendor's endpoint and license key, which is where nothing about one middleware belongs. Settings gain [middleware], one [middleware.<name>] table for each middleware that has settings, written with the middleware's full name, so [middleware.example.cleanup] is the example.cleanup middleware's. A table holds values and arrays, and a table within one is the table of the longer name it spells and never a setting, so a middleware never sees another's settings. 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. The section refuses a value where only tables stand and a name no middleware could have, and the registry refuses at startup a table at a name that no module it runs supplies, with the names that could be written, as it refuses an entry naming such a middleware. A middleware with no table of its own reads its module's table, as the stock modules do. The fixture module gains a middleware with a table of its own, and tests cover a middleware reading its table and not a longer name's, a table at a name nothing supplies refused on both shapes, a key the middleware does not know refused with the table and the key named, and the section's own refusals. The guide documents the section beside the shared tables and says where a middleware's settings live, and the changelog says what it adds.
# Conflicts: # crates/trusted-server-core/src/integrations/registry.rs
Two doc comments used a vendor's middleware as their example of a deeper table. The examples now use the fixture's example names, as the guide does.
Series 38 had an issue and a pull request but no design document. This one describes the [middleware.<name>] section, how a middleware reads its table, what is checked and when, what each adapter does with a refused table, consent and privacy, rollout, and the joins that have no test. It also lists what the series leaves out.
The review found two behaviors the design did not state. A table under a quoted key that holds a dot is accepted and never read. The startup check refuses a first part of a deselected module's name, a table nobody wrote, before the table that was written, so the sentence saying the module is not selected is missing. The design now states both as the code has them and lists the code change each needs under Open questions. It also corrects what runs a module, how often a table is read on each adapter, what a refusal does to every route and the crate under crates/middleware. It adds the rollout order for ts and for builders that a shared table runs, says that a table change leaves stored pages unread, and fixes the status date and the issue citation. One sentence of the configuration guide said a middleware refuses a key it does not know, which holds only when its settings type denies unknown fields. The sentence now says so.
Round 2 found no blocking issues and four small points. GET /health is left out of the routes a refusal fails on Fastly, which answers it before it builds anything, and on Spin, whose error router answers it with 200. On Axum, which builds the registry once, the 500 lasts until the process restarts. The refusal for a builder that a shared table runs now names the first part of the name, as Failure handling explains. The test description says that only the assertion on the testing.nothing message proves the list of supplied names, because every refusal message carries the list. Section 3 names the three code comments left for a later change.
This was referenced Oct 17, 2026
jwrosewell
changed the title
jwrosewell
marked this pull request as ready for review
October 19, 2026 20:23
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
[middleware.<name>].Changes
crates/trusted-server-core/srcdocs/superpowersdocs/guideCHANGELOG.mdCloses
Closes #1331
Spec
Spec: middleware-settings
Test plan
CI on this pull request at bf80fec passed all 20 checks.
cargo test-fastly && cargo test-axumcargo clippy-fastly && cargo clippy-axumcargo fmt --all -- --checkcd crates/trusted-server-js/lib && npx vitest runcd crates/trusted-server-js/lib && npm run formatcd docs && npm run formatcargo build --package trusted-server-adapter-fastly --release --target wasm32-wasip1fastly compute serveChecklist
unwrap()in production code (clippy deniesunwrap_usedin CI)logmacros as AGENTS.md asks (notprintln!)On top of the origin's redirect to itself kept on the reader's address (#1378). Issue: #1331.
Kept current. This update only merges the pull request below (#1378), which brings Tech Lab's
mainat 7aa5c99, the changes made lower in the stack andfiftyone-caching4.5.13 (#1372).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.How it works.
[middleware.example.cleanup]is theexample.cleanupmiddleware'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 toexample.cleanupand theexamplemiddleware never sees it.Settings::middleware_config, which refuses a key the middleware does not know and a value that fails its validation, naming the table.[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.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
[middleware.<name>]The other commits merge the branch below into this one, and through it Tech Lab main at 7aa5c99.
What is not in this pull request