Fix #3729: Support optional parameters in RewriteLocationResponseHeader filter

[belljun3395]

Fix #3729: Support optional parameters in RewriteLocationResponseHeader filter

Summary

This PR resolves issue #3729 by adding overloaded methods for the RewriteLocationResponseHeader filter, enabling flexible YAML configuration with optional parameters.

Problem

Users were unable to use the RewriteLocationResponseHeader filter in YAML configuration with optional parameters. The filter only supported the full 4-parameter signature, causing failures when users tried to use shorter forms:

# This failed with IllegalArgumentException
filters:
  - RewriteLocationResponseHeader=AS_IN_REQUEST, Location, ,

Error:

Unable to find operation interface org.springframework.web.servlet.function.HandlerFilterFunction for 
rewriteLocationResponseHeader with args {_genkey_0=AS_IN_REQUEST, _genkey_1=Location}

Solution

Added method overloads to support 1, 2, 3, and 4 parameters in both FilterFunctions and AfterFilterFunctions:

// New overloads added
@Shortcut
static HandlerFilterFunction<...> rewriteLocationResponseHeader(String stripVersion)

@Shortcut  
static HandlerFilterFunction<...> rewriteLocationResponseHeader(String stripVersion, String locationHeaderName)

@Shortcut
static HandlerFilterFunction<...> rewriteLocationResponseHeader(String stripVersion, String locationHeaderName, String hostValue)

// Existing 4-parameter method unchanged
@Shortcut
static HandlerFilterFunction<...> rewriteLocationResponseHeader(String stripVersion, String locationHeaderName, String hostValue, String protocolsRegex)

Changes Made

Code Changes

• FilterFunctions.java: Added 3 new overloaded methods with @Shortcut annotation
• AfterFilterFunctions.java: Added corresponding overloads for API consistency
• ServerMvcIntegrationTests.java: Added comprehensive tests for all parameter combinations
• rewritelocationresponseheader.adoc: Updated documentation with usage examples

YAML Configuration Support

Now supports all these configurations:

filters:
  # Minimal configuration - only stripVersion  
  - RewriteLocationResponseHeader=AS_IN_REQUEST
  
  # Specify header name
  - RewriteLocationResponseHeader=AS_IN_REQUEST, Location
  
  # Specify custom host value  
  - RewriteLocationResponseHeader=AS_IN_REQUEST, Location, api.example.com
  
  # Full configuration with protocols regex
  - RewriteLocationResponseHeader=AS_IN_REQUEST, Location, api.example.com, https?|ftps?

Testing

New Tests Added

• rewriteLocationResponseHeaderWithMinimalArgsWorks() - Tests 1 parameter
• rewriteLocationResponseHeaderWithTwoArgsWorks() - Tests 2 parameters
• rewriteLocationResponseHeaderWithThreeArgsWorks() - Tests 3 parameters
• Existing 4-parameter test unchanged

Test Results

Tests run: 4, Failures: 0, Errors: 0, Skipped: 0
- ✅ rewriteLocationResponseHeaderWorks (existing)
- ✅ rewriteLocationResponseHeaderWithMinimalArgsWorks  
- ✅ rewriteLocationResponseHeaderWithTwoArgsWorks
- ✅ rewriteLocationResponseHeaderWithThreeArgsWorks

Verification

All tests verify the Location header is correctly rewritten:

• 1 param: Uses default Location header and request Host
• 2 params: Uses specified header name and request Host
• 3 params: Uses specified header name and custom host
• 4 params: Uses all custom parameters (existing behavior)

Backward Compatibility

✅ 100% backward compatible

• All existing configurations continue to work unchanged
• No breaking changes to public APIs
• Existing tests pass without modification

Documentation Updates

Updated the AsciiDoc documentation to include:

• Multiple configuration examples
• Explanation of default values for optional parameters
• Clear usage patterns for different scenarios

Code Quality

• ✅ Compilation: No errors or warnings
• ✅ Style: Passes Spring Java Format and Checkstyle
• ✅ Testing: Comprehensive test coverage for all overloads
• ✅ Consistency: Same pattern used in both FilterFunctions and AfterFilterFunctions

Related Issue

Resolves #3729

Checklist

• Code compiles without errors
• All tests pass (existing + new)
• Backward compatibility maintained
• Documentation updated
• Code follows project style guidelines
• Comprehensive test coverage added