Change of URL encoding behaviour doesn't seem right

See original GitHub issue

This issue is probably related to #1189 but is focused on the encoding of path variables instead. We’ve recently upgraded to Spring Cloud to Hoxton.SR3 which includes a bump of Spring Cloud OpenFeign from 2.2.1.RELEASE to 2.2.2.RELEASE. This patch version bumps OpenFeign from 10.4.0 to 10.7.4 which seems to contain quite a few important changes.

In particular, there is a change of behaviour around url encoding (#1138) which in our case has broken a couple of things with using path variables. I’ve created a sandbox project at https://github.com/sguillope/openfeign-url-encoding-issue to make it easier to reproduce the issue.

The 2 problems we’ve hit are as follows when using a path variable:

The colon : character now gets url-encoded to %3A. While not really incorrect, it’s not actually required as a colon is a valid character in a path segment (https://tools.ietf.org/html/rfc3986#section-3.3), except for one case which shouldn’t apply here. This only broke our integration tests, not production code, so we can easily fix that.
The most problematic one is the handling of the forward slash / character. With the latest version, it doesn’t get url-encoded in path variables. Fortunately this was caught by our integration tests, otherwise it would have broken our production code. We can’t pre-encode it because it will then get double-encoded as %252F instead of %2F.

To summarise:

Input	Result	Expected
`a:path/variable`	`a%3Apath/variable`	`a:path%2Fvariable`
`path/variable`	`path/variable`	`path%2Fvariable`
`a:path`	`a%3Apath`	`a:path`

Let me know if you need more details. Thanks

Issue Analytics

State:
Created 4 years ago
Reactions:1
Comments:15 (5 by maintainers)

Top GitHub Comments

4reactions

sguillopecommented, Mar 16, 2020

Hi @kdavisk6, thanks for the thorough reply, much appreciated.

Unfortunately because we use Spring Cloud OpenFeign, I believe there isn’t much control we have over the decodeSlash parameter (arguably that’s a Spring Cloud problem)

That said, I’ve added more test cases to my test project sguillope/openfeign-url-encoding-issue with using pre-encoded path variables.

Test Case	Input	Result	Expected
Encoded `/`	`path%2Fvariable`	`path/variable`	`path%2Fvariable`
Encoded `:` and `/`	`a%3Apath%2Fvariable`	`a%3Apath/variable`	`a%3Apath%2Fvariable`
Unencoded `:` and encoded `/`	`a:path%2Fvariable`	`a%3Apath%252Fvariable`	`a:path%2Fvariable`
Encoded `:` and unencoded `/`	`a%3Apath/variable`	`a%253Apath/variable`	?

For some reason, when Feign detects the variable as already being encoded, it ends up decoding %2F back to /.

As you can see without control over the decodeSlash behaviour it’s impossible to get the / to be encoded.

2reactions

apereznavarro99commented, Jan 25, 2022

Same issue here, in my case I was trying to integrate with Google Analitycs 4, they require parameters with “:” in the requests.

I solved it by changing this

@FeignClient
interface AwesomeClient {

    @PostMapping("/awesome_request")
    fun request(
        @RequestParam("param_with_colon") param: String
    )
}

To this

@FeignClient
interface AwesomeClient {

    @PostMapping("/awesome_request")
    fun request(
        @SpringQueryMap(encoded = true) params: ParamWithColon
    )
}

class ParamWithColon(
    val param_with_colon: String 
)

Top Results From Across the Web

URL encoding using the new Spring UriComponentsBuilder

What solved my issue was encoding the value manually + using URI instead of the string value (both were very important). Before: restTemplate.exchange( ......

URI Encoding Done Right - Unspecified Behaviour

It deliberately does not encode any URI delimiters (such as : / ? & and =). The reason for this is that it...

34602 – mod_rewrite fails to correctly deal with URLS that ...

I have a simple redirect rule that looks something like this: RewriteCond %{QUERY_STRING} Insurrection=rss RewriteRule ^svn/(.

urldecode - Manual - PHP

When the client send Get data, utf-8 character encoding have a tiny problem with the urlencode. Consider the "º" character.

785809 - Security: Chrome does not percent-escape the URL ...

Seems correct to me. ... > codepath into the command line arguments of the target application. That seems like broken behaviour to me....