Allow to redefine global request body configuration per endpoint
What does this MR do and why?
Contributes to https://gitlab.com/gitlab-org/gitlab/-/issues/554848
Problem
Currently, GitLab's request body size limiting operates with a single global configuration mode (disabled, logging, or enforced). However, different API endpoints have varying requirements. Some endpoints may need stricter enforcement even when the global setting is more permissive, while others may need to bypass restrictions for legitimate use cases.
Current limitations:
- Global body limit mode applies uniformly to all endpoints
- Cannot selectively enforce stricter limits on specific endpoints
- Cannot bypass global restrictions for specific endpoints that require larger payloads
- Limited flexibility for gradual rollout of enforcement policies
Solution
Implement per-endpoint body limit mode configuration that allows overriding the global setting on a route-by-route basis.
Key capabilities:
- Mode Override: Allow endpoints to specify their own mode (disabled, logging, enforced) regardless of global configuration
- Size Override: Maintain existing per-endpoint size limit configuration
- Fallback Behavior: Use global configuration when no endpoint-specific mode is defined
- Context-based Implementation: Leverage request context to pass mode information through the middleware chain
References
https://gitlab.com/gitlab-org/gitlab/-/issues/554848+
How to set up and validate locally
- Start GitLab development environment
- Test different mode combinations:
# Test with large payload
curl -X POST -d "$(head -c 200000 /dev/zero | tr '\0' 'a')" http://gdk.test:3000/api/v4/projects/1/remote_mirrors
# expected: Request Entity Too Large
# Test with small payload
curl -X POST -d "$(head -c 20000 /dev/zero | tr '\0' 'a')" http://gdk.test:3000/api/v4/projects/1/remote_mirrors
# expected: {"message":"404 Project Not Found"}
MR acceptance checklist
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Related to #554848