Release 2.3.0
Summary
Release 2.3.0 hardens rate-limit client partition fallback behavior when HttpContext.Connection.RemoteIpAddress is unavailable.
Highlights
- Added explicit configuration for unknown-client rate-limit fallback behavior.
- Changed unresolved-client fallback behavior so requests no longer silently collapse into one shared
"unknown-client"bucket by default. - Added warning logging when rate limiting must use the fallback client partition path.
- Preserved the safer design of using ASP.NET Core Forwarded Headers Middleware as the trusted source for client IP resolution instead of parsing raw
X-Forwarded-Forvalues directly. - Expanded documentation around trusted proxy configuration,
KnownProxies,KnownNetworks, and middleware ordering.
New Configuration
Two rate-limiting settings were added:
"UseSharedUnknownClientPartition": false,
"UnknownClientPartitionKey": "unknown-client"By default, unresolved clients now receive a per-request fallback partition. Set UseSharedUnknownClientPartition to true only when unresolved clients should intentionally share the configured unknown-client bucket.
Validation
This release also adds test coverage for:
- Resolved client IP partitioning.
- Default per-request fallback partitioning.
- Explicit shared fallback partitioning.
- Fallback warning logging.
- Rate-limiting option binding and validation.
Notes
This is a minor release because it adds new configuration surface and changes fallback behavior while preserving the stable 2.x package identity, template short name, template options, and default scaffold purpose.
Production deployments behind reverse proxies, load balancers, ingress controllers, CDNs, or gateways should verify forwarded-header trust configuration so rate limiting and request logging see the corrected client IP address.