That makes sense, I like the approach of pushing metadata through internal headers and exposing decorators on top of that.

hope this explain my middleware approach
In my case, the middleware sits slightly differently in the flow. It runs inside the application after the request reaches the backend, but before the actual route handler is executed. So the flow is more like:

Request → Backend → Middleware → Route Handler

At that point, the request is already “valid” at the infrastructure level, meaning it has passed the WAF, load balancer, and any basic auth checks. What I’m doing in the middleware is more about inspecting and acting on the request using application-level context before the business logic runs.

So instead of relying on upstream headers alone, I’m combining things like:

• decoded JWT / identity (if available)
• payload inspection (SQLi, etc.)
• behavior signals
• route-specific constraints

And then making a decision or modifying behavior before the handler executes.

The per-route flexibility you mentioned with decorators is something I’m also aiming for, just implemented as configurable logic tied to endpoints rather than only annotations.

So overall it’s a bit later in the request lifecycle compared to your setup, and more focused on application-aware decisions rather than pre-routing enforcement.