Stop double-encoding path in various filter functions

[rworsnop]

Fixes gh-3436

[Sroca3]

@spencergibb does closing the associated issue mean this is going to get merged at some point?

[spencergibb]

No, just if you're going to submit a PR immediately after opening an issue, the issue is unnecessary.

[dvag-yannick-reifschneider]

I have encountered this issue as well. As a workaround I implemented a custom filter function, which reverses the url decoding. You have to add this filter after StripPrefix, RewritePath or other affected filters.

public class UrlDecodeFilter {
    public static HandlerFilterFunction<ServerResponse, ServerResponse> urlDecode() {
        return HandlerFilterFunction.ofRequestProcessor((ServerRequest request) -> {
            String urlDecodedUri = UriUtils.decode(request.uri().toString(), StandardCharsets.UTF_8);
            return ServerRequest.from(request).uri(URI.create(urlDecodedUri)).build();
        });
    }
}

[jensmatw]

I haven't seen this and opened another PR for rewritePath. i like the different approach, using build(true) to tell the builder that it is already encoded but maybe there is something to consider, at least for rewritePath there is a difference in the behaviour between our different solutions:
if we replace getRawPath() with getPath() to get the path initially to apply the user created regex, it is applied to the decoded string, if we use build(true) in the end to prevent double encoding the regex is applied on the encoded String