Add Buffer Overflow Protection to RouteValues Parameter Allocation
Summary
Currently, RouteValues uses a fixed-size buffer (8 parameters) which can throw InvalidOperationException if exceeded. While current routes are safe (max 4 parameters), we should add safeguards for future extensibility and general-purpose routing library use.
Current State
- Fixed buffer size: 8 parameters
- Current max usage: 4 parameters (TestsBadge route:
{platform}/{owner}/{repo}/{branch})
- Risk:
InvalidOperationException: "RouteValues buffer is full." if buffer size exceeded
- Recent optimization: Buffer sharing implemented (66% allocation reduction proven)
Problem Scenarios
- Future route expansion: Adding routes with >8 parameters
- NuGet package usage: External users with complex routing needs
- RegexPattern routes: Dynamic parameter extraction could exceed limits
- Runtime failures: Hard crashes instead of graceful degradation
Proposed Solutions
Option 1: Dynamic Buffer Sizing ⭐ (Recommended)
- Analyze route patterns at startup (
GetParameterCount() on IRoutePattern)
- Calculate optimal buffer size:
Math.Max(8, maxParams + 2) (safety margin)
- Zero runtime overhead, no exceptions
Option 2: Graceful Overflow Handling
- Keep current size but handle overflow gracefully in
RouteValues.Set()
- Resize buffer or fallback to
Dictionary<string, (int, int)> when needed
- Runtime flexibility but allocation cost on overflow
Option 3: Hybrid Approach
- Smart sizing + overflow protection
- Best reliability with performance guarantees
Implementation Tasks
Test Scenarios
- ✅ Normal operation (≤8 parameters)
- ✅ Buffer full (exactly 8 parameters)
- ❌ Buffer overflow (>8 parameters) - should not throw
- ❌ Malformed patterns with excessive parameters
- ❌ Edge cases: empty routes, null parameters
- ✅ Performance regression tests vs current implementation
Success Criteria
- No runtime exceptions from buffer overflow
- Performance impact < 5% for normal cases
- 100% test coverage for buffer edge cases
- Backward compatibility with existing route definitions
- Clear documentation for buffer sizing recommendations
Priority
Medium - Current routes are safe, but important for:
- Future extensibility
- NuGet package reliability
- Production robustness
- General-purpose routing library goals
Related Work
- Buffer allocation optimization: 66% reduction achieved
- URL decoding implementation: Complete
- Case-insensitive routing: Complete
- CORS handler migration: Complete
Note: This issue tracks the safety enhancement. Current buffer sharing optimization is complete and working as intended.
Add Buffer Overflow Protection to RouteValues Parameter Allocation
Summary
Currently,
RouteValuesuses a fixed-size buffer (8 parameters) which can throwInvalidOperationExceptionif exceeded. While current routes are safe (max 4 parameters), we should add safeguards for future extensibility and general-purpose routing library use.Current State
{platform}/{owner}/{repo}/{branch})InvalidOperationException: "RouteValues buffer is full."if buffer size exceededProblem Scenarios
Proposed Solutions
Option 1: Dynamic Buffer Sizing ⭐ (Recommended)
GetParameterCount()onIRoutePattern)Math.Max(8, maxParams + 2)(safety margin)Option 2: Graceful Overflow Handling
RouteValues.Set()Dictionary<string, (int, int)>when neededOption 3: Hybrid Approach
Implementation Tasks
GetParameterCount()method toIRoutePatterninterfaceExactPattern,TemplatePattern,RegexPatternRouteResolverconstructorRouteValues.Set()methodTest Scenarios
Success Criteria
Priority
Medium - Current routes are safe, but important for:
Related Work
Note: This issue tracks the safety enhancement. Current buffer sharing optimization is complete and working as intended.