pub struct MiddlewareConfig {
pub rate_limit: Option<RateLimitConfig>,
pub cache: Option<CacheConfig>,
pub auth: Option<AuthConfig>,
pub rewrite_request: Vec<RewriteRuleConfig>,
pub rewrite_response: Vec<RewriteRuleConfig>,
pub ip_allow: Vec<String>,
pub ip_deny: Vec<String>,
pub timeout_ms: Option<u64>,
pub max_body_size: Option<u64>,
}Fields§
§rate_limit: Option<RateLimitConfig>§cache: Option<CacheConfig>§auth: Option<AuthConfig>§rewrite_request: Vec<RewriteRuleConfig>§rewrite_response: Vec<RewriteRuleConfig>§ip_allow: Vec<String>§ip_deny: Vec<String>§timeout_ms: Option<u64>timeout_ms — if the route (including all its other middleware)
doesn’t produce a response within this many milliseconds, the client
gets 504 Gateway Timeout instead of waiting further. See
crate::timeout for the underlying mechanism and its limitations.
max_body_size: Option<u64>max_body_size — reject this route’s request with 413 Payload Too Large if its body exceeds this many bytes.
This is a route-specific ceiling on top of the global, process-wide
RWS_CONFIG_MAX_BODY_SIZE_IN_BYTES (see crate::entry_point::get_max_body_size)
— e.g. a small JSON API route can be capped stricter than a
file-upload route without lowering the global limit for everyone.
It is not a substitute for the global limit: by the time any
route-level middleware runs, Request (including its body) has
already been fully read off the socket — route matching itself
requires the complete request, so a per-route check can only run
after that memory is already spent, not before. The global limit is
what protects total server memory from an oversized upload;
max_body_size protects only this route’s own logic/upstream from
an oversized-but-still-within-the-global-limit body.
Trait Implementations§
Source§impl Clone for MiddlewareConfig
impl Clone for MiddlewareConfig
Source§fn clone(&self) -> MiddlewareConfig
fn clone(&self) -> MiddlewareConfig
1.0.0 (const: unstable) · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source. Read more