ADR 0115 (proposed): a route may state the largest request body it carries #123

2026-09-26T13:10:41Z

jschoubben commented

2026-09-26 13:10:41 +00:00

Proposed, for your review — nothing is implemented and no design rests on it.

This is what feat/registry-public-route turns out to need. That branch (controller + catalogue, finished and pushed, never proposed) adds a per-route body limit so the artifact store can have a public name that can actually be pushed to. It cannot merge as written: main has since rewritten the route-proxy under ADR 0108, whose routing table the branch's version predates — 8 conflict regions in main.go and 8 in its tests, which is a port, not a conflict resolution.

And the port lands on a wall the repository put there on purpose. 0108 is accepted and says: "The set is closed, and it is these four… A fifth is an amendment to this record, deliberately — each addition should be earned by a dependent that exists."

So the question is not where to put a field, it is whether the fifth is earned. I think it is, and the record makes that case: a registry takes image layers in single requests of gigabytes; the predecessor served that exact name with a body-size middleware in front; without one the proxy refuses the push at its own default before the registry sees it. A public registry name that cannot state its limit is a name nothing can be pushed to — written, reported served, failing on first use.

The record also rejects the cheap merge explicitly: the limit could ride beside certificate verification as a transport detail on a rule, which is how the existing branch would most easily merge. A body limit refuses requests, 0108 exists to keep every request-refusing behaviour in one place, and a closed set with an exception written next to it is not a closed set.

If you accept it, the port is mechanical and I'll do it: the branch's catalogue half and route vocabulary apply cleanly, and only the proxy needs rewriting onto the rule/policy model. If you'd rather not widen the set, the alternative in the record is leaving that one name on the adopted ingress — which keeps the predecessor's proxy alive for exactly one route.

Checks: cycle 287 documents, the chain holds; records 105, all passed; index regenerated and current.

**Proposed, for your review** — nothing is implemented and no design rests on it. This is what `feat/registry-public-route` turns out to need. That branch (controller + catalogue, finished and pushed, never proposed) adds a per-route body limit so the artifact store can have a public name that can actually be pushed to. It cannot merge as written: `main` has since rewritten the route-proxy under **ADR 0108**, whose routing table the branch's version predates — 8 conflict regions in `main.go` and 8 in its tests, which is a port, not a conflict resolution. And the port lands on a wall the repository put there on purpose. 0108 is accepted and says: *"The set is closed, and it is these four… A fifth is an amendment to this record, deliberately — each addition should be earned by a dependent that exists."* So the question is not where to put a field, it is whether the fifth is earned. I think it is, and the record makes that case: a registry takes image layers in single requests of gigabytes; the predecessor served that exact name with a body-size middleware in front; without one the proxy refuses the push at its own default before the registry sees it. A public registry name that cannot state its limit is a name nothing can be pushed to — written, reported served, failing on first use. The record also **rejects the cheap merge explicitly**: the limit could ride beside certificate verification as a transport detail on a rule, which is how the existing branch would most easily merge. A body limit refuses requests, 0108 exists to keep every request-refusing behaviour in one place, and a closed set with an exception written next to it is not a closed set. If you accept it, the port is mechanical and I'll do it: the branch's catalogue half and route vocabulary apply cleanly, and only the proxy needs rewriting onto the rule/policy model. If you'd rather not widen the set, the alternative in the record is leaving that one name on the adopted ingress — which keeps the predecessor's proxy alive for exactly one route. Checks: cycle 287 documents, the chain holds; records 105, all passed; index regenerated and current.

jschoubben added 1 commit 2026-09-26 13:10:41 +00:00

ADR 0115 (proposed): a route may state the largest request body it carries 81bdf8df56

ADR 0108 closed the policy set at four and priced a fifth: earned by a dependent that exists. The
registry's public door is one. A registry takes layers in single requests of gigabytes, the
predecessor served that name with a body-size middleware, and without one the proxy refuses the push
at its own default before the registry sees it — so a public name that cannot state its limit is a
public name nothing can be pushed to.

Rejects the cheap merge deliberately: the implementation waiting on feat/registry-public-route could
carry the limit beside certificate verification as a transport detail, but a body limit refuses
requests, and a closed set with an exception written next to it is not a closed set.

jschoubben commented

2026-09-26 13:23:08 +00:00

Closing this without merging: it should not have been written.

A maximum request body is proxy configuration, not one of the four policies ADR 0108 closed. The record's own "rejected options" section argued that a body limit refuses requests and therefore belongs in the policy set — that reasoning is wrong, or at least proves too much. By it, the existing insecure setting on a route would also be a policy: it decides whether a backend's certificate is trusted, and an untrusted one fails the request. It sits on a route as a plain setting because that is what it is, and a size limit is the same kind of thing.

0108 closed a set of policies applied to a request — what a name admits, who may reach it, where it goes. Tuning the proxy that serves a route is a different axis, and nothing in 0108 says the proxy takes no settings. So no amendment is needed, the set stays at four, and the limit goes where insecure goes.

What happens instead: the limit is implemented as an ordinary per-route proxy setting, ported onto the rule model main now has, with a comment saying plainly that it is configuration rather than a policy so the next reader does not have to re-derive that.

Separately, and the reason this came up at all: the distribution-gate module on feat/registry-public-route is not being built. It gave the seat-holding artifact store a second, public, authenticated door over the same filesystem, conflating the mesh's own internal store with the distinct case of hosting a registry publicly as a service. Issue 108 now records that (hq #124). The body-limit setting is worth having on its own terms, for whatever route needs it.

Closing this without merging: it should not have been written. A maximum request body is **proxy configuration**, not one of the four policies ADR 0108 closed. The record's own "rejected options" section argued that a body limit refuses requests and therefore belongs in the policy set — that reasoning is wrong, or at least proves too much. By it, the existing `insecure` setting on a route would also be a policy: it decides whether a backend's certificate is trusted, and an untrusted one fails the request. It sits on a route as a plain setting because that is what it is, and a size limit is the same kind of thing. 0108 closed a set of **policies applied to a request** — what a name admits, who may reach it, where it goes. Tuning the proxy that serves a route is a different axis, and nothing in 0108 says the proxy takes no settings. So no amendment is needed, the set stays at four, and the limit goes where `insecure` goes. What happens instead: the limit is implemented as an ordinary per-route proxy setting, ported onto the rule model `main` now has, with a comment saying plainly that it is configuration rather than a policy so the next reader does not have to re-derive that. Separately, and the reason this came up at all: the `distribution-gate` module on `feat/registry-public-route` is **not** being built. It gave the seat-holding artifact store a second, public, authenticated door over the same filesystem, conflating the mesh's own internal store with the distinct case of hosting a registry publicly as a service. Issue 108 now records that (hq #124). The body-limit setting is worth having on its own terms, for whatever route needs it.

jschoubben closed this pull request

2026-09-26 13:23:12 +00:00

Pull request closed

This pull request cannot be reopened because the branch was deleted.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/hq#123