Aias00 opened a new issue, #7441: URL: https://github.com/apache/shenyu/issues/7441
## Is there an existing issue for this? - [x] I searched existing open and closed issues. ## Current Behavior The shared fault-tolerance fallback handler fails to recognize a relative fallback URI that is identical to the current request when its query contains percent-encoded characters. For a request to `http://localhost/fallback?reason=a%26b` and a configured fallback `/fallback?reason=a%26b`, the handler returns `302 Location: /fallback?reason=a%26b` instead of taking the self-target error path. Following that redirect and triggering fallback again repeats the same redirect. `UriUtils.getPathWithParams()` combines the raw path with `URI.getQuery()`, which decodes the query. Its result is `/fallback?reason=a&b`. `FallbackHandler` compares that result with the raw configured target, so equality fails. The internal `fallback:` branch uses the same inconsistent comparison. ## Expected Behavior An identical fallback target should invoke `withoutFallback()` rather than redirecting or redispatching to itself, including when query values contain encoded characters. ## Steps To Reproduce 1. Configure a Sentinel, Resilience4J, or Hystrix fallback URI as `/fallback?reason=a%26b`. 2. Make the fallback endpoint match a rule that triggers fallback. 3. Request `/fallback?reason=a%26b`. 4. Observe a `302` whose `Location` is the same relative URL. Repeating the request repeats the redirect. A direct reproduction with the current source and Spring's mock exchange: ```java URI current = URI.create("http://localhost/fallback?reason=a%26b";); URI target = URI.create("/fallback?reason=a%26b"); System.out.println(UriUtils.getPathWithParams(current)); // /fallback?reason=a&b MockServerWebExchange exchange = MockServerWebExchange.from( MockServerHttpRequest.method(HttpMethod.GET, current)); // handler is a FallbackHandler whose withoutFallback returns Mono.empty(). handler.fallback(exchange, target, new RuntimeException("upstream failed")).block(); // status = 302 FOUND, Location = /fallback?reason=a%26b // withoutFallback is never called. ``` ## Environment ShenYu `2.7.2-SNAPSHOT`, `master` at `67596c1d228b62da75cd0a0ecb47d0ac5d995384`, Java 17. ## Location And Impact - [UriUtils.java:87](https://github.com/apache/shenyu/blob/67596c1d228b62da75cd0a0ecb47d0ac5d995384/shenyu-common/src/main/java/org/apache/shenyu/common/utils/UriUtils.java#L87): decoded query returned alongside raw path. - [FallbackHandler.java:68](https://github.com/apache/shenyu/blob/67596c1d228b62da75cd0a0ecb47d0ac5d995384/shenyu-plugin/shenyu-plugin-base/src/main/java/org/apache/shenyu/plugin/base/fallback/FallbackHandler.java#L68): internal fallback comparison. - [FallbackHandler.java:84](https://github.com/apache/shenyu/blob/67596c1d228b62da75cd0a0ecb47d0ac5d995384/shenyu-plugin/shenyu-plugin-base/src/main/java/org/apache/shenyu/plugin/base/fallback/FallbackHandler.java#L84): relative redirect comparison. Severity: Medium. Confidence: high. This breaks the self-target guard under an operator-configured fallback with an encoded query. Absolute fallback URLs follow a separate full-URI comparison. ## Suggested Fix And Regression Coverage Use a consistent raw representation for path/query comparison, such as `getRawPath()` with `getRawQuery()`. Verify both relative redirects and internal `fallback:` dispatch with encoded query values, while retaining plain-query behavior. ## Validation And Related Issues - Compiled the actual current `UriUtils` and `FallbackHandler` sources and ran a mock-exchange harness: three identical `302` redirects, zero `withoutFallback` calls. - Existing `UriUtilsTest`: 5 tests passed. Existing `FallbackHandlerTest`: 3 tests passed. Their current cases do not cover encoded queries. - Independent review confirmed the source path and guard mismatch. - #5494 concerns lost host/port information in fallback requests; it does not cover this encoded-query self-target guard. - No full gateway integration deployment was run. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
