Module middleware 

MPL middleware for request/response processing

Architecture Note

MPL validation is implemented in the request handlers (proxy.rs) rather than as Tower middleware. This is the standard pattern for axum when body inspection is required, because:

1. Request bodies can only be consumed once - middleware would need to buffer the entire body, parse it, then reconstruct it for downstream handlers
2. Validation logic is tightly coupled with routing (different paths may have different validation requirements)
3. Response enrichment (adding MPL headers) is simpler in handlers

The proxy_handler in handlers.rs calls ProxyState::forward_request() which:

• Parses MPL envelopes from body or X-MPL-SType header
• Validates against registered schemas
• Evaluates QoM profiles
• Verifies semantic hashes
• Returns 400 in strict mode for failures
• Adds X-MPL-QoM-Result headers to responses

This middleware layer is available for future use cases like:

• WebSocket connection upgrade interception
• Request logging/tracing
• Rate limiting based on SType

Structs

MplMiddleware

MPL middleware layer for future extensibility

MplMiddlewareService

MPL middleware service