6

I have a simple echo controller

@RestController public class EchoController { @GetMapping(path = "/param", produces = MediaType.TEXT_PLAIN_VALUE) String echoParam(@RequestParam("p") String paramValue) { return paramValue; } @GetMapping(path = "/path-variable/{val}", produces = MediaType.TEXT_PLAIN_VALUE) String echoPathVariable(@PathVariable("val") String val) { return val; } } 

One of its methods echoes the value of a parameter it was presented; the second does the same with a value provided via URI.

I have the following tests:

@Autowired private WebTestClient webTestClient; @Test public void rawPlus_inQueryParam() { String value = "1+1"; String response = getValueEchoedThroughQueryParam(value); assertThat(response, is(equalTo(value))); } @Test public void urlencodedPlus_inQueryParam() { String value = "1%2B1"; String response = getValueEchoedThroughQueryParam(value); assertThat(response, is(equalTo(value))); } private String getValueEchoedThroughQueryParam(String value) { return webTestClient.get() .uri(builder -> { return builder .path("/param") .queryParam("p", value) .build(); }) .exchange() .expectStatus().is2xxSuccessful() .expectBody(String.class) .returnResult() .getResponseBody(); } 

Both tests just send a string via the query parameter, read the response and assert that the content was echoed correctly.

First test fails:

java.lang.AssertionError: Expected: is "1+1" but: was "1 1" 

Second test passes.

Looks like in the second test, the WebTestClient url-encodes the value (actually, it just url-encodes the percent character), then the web-server url-decodes it, and everything is ok. But in the first test, the client does not url-encode the plus character, but the server does url-decode it, hence it gets a space character.

This looks like an inconsistency. I doubt I could do something stupid to cause it because everything works in the default mode; actually, the controller I show here is almost the only code the application has (Application class itself is default, I did not touch it after it was generated).

Just to compare: when passing the same data in URI, everything works correctly. The following tests pass:

@Test public void rawPlus_inPathVariable() { String value = "1+1"; String response = getValueEchoedThroughPathVariable(value); assertThat(response, is(equalTo(value))); } @Test public void urlencodedPlus_inPathVariable() { String value = "1%2B1"; String response = getValueEchoedThroughPathVariable(value); assertThat(response, is(equalTo(value))); } private String getValueEchoedThroughPathVariable(String value) { return webTestClient.get() .uri("/path-variable/" + value) .exchange() .expectStatus().is2xxSuccessful() .expectBody(String.class) .returnResult() .getResponseBody(); } 

The questions are:

  1. Is this a bug in Spring Boot (or one of the components it uses)?
  2. If not, did I do something wrong?
  3. And the practical question: how can you pass a query parameter value that contains plus character in tests written against WebTestClient? If I don't url-encode it manually, it gets url-decoded by the web-server; if I do, it gets url-encoded second time, so the server gets (after url-decoding) an url-decoded version.

Spring Boot version is 2.1.4.RELEASE (the most recent at the moment of writing).

POM follows:

<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.1.4.RELEASE</version> <relativePath /> <!-- lookup parent from repository --> </parent> <groupId>com.example</groupId> <artifactId>springboot-plus-in-query-string</artifactId> <version>0.0.1-SNAPSHOT</version> <name>springboot-plus-in-query-string</name> <description>Demo project for Spring Boot</description> <properties> <java.version>1.8</java.version> </properties> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-webflux</artifactId> <scope>test</scope> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build> </project> 

The project is available at GitHub: https://github.com/rpuch/springboot-plus-in-query-string

Just run the tests (mvn clean test).

4
  • possible duplicate? stackoverflow.com/questions/44455594/… Commented May 4, 2019 at 14:18
  • @javapedia.net it does not look like a duplicate. There, the OP wants to disable the decoding. Here, I want to understand why the encoding+decoding is inconsistent and know how to fix it: by fixing a bug in Tomcat, by fixing a bug in web-client, or doing something else. Commented May 4, 2019 at 16:11
  • This behaviour is the standard. Have you tried "1%2B1"? Commented May 4, 2019 at 17:08
  • @Bohemian yes I did. It is in the question :) % gets encoded, so we get double-encoded plus character in the request; web-server decodes it one time, and the controller gets 1%2B1 and not 1+1. Commented May 4, 2019 at 19:55

2 Answers 2

8

See this issue

The key to understand this, is that different degrees of encoding are applied to the URI template vs URI variables. In other words given:

http://example.com/a/{b}/c?q={q}&p={p}

The URI template is everything except for the URI variable placeholders. However the code snippet you showed only builds a URI literal without any variables, so the level encoding is the same, only illegal characters, no matter which method is used.

So it would also have to be something like:

.queryParam("foo", "{foo}").buildAndExpand(foo)

Therefore the idea is to use something like:

builder .path("/param") .queryParam("p", "{value}") .build(value) 

to get the query param encoded.

Sign up to request clarification or add additional context in comments.

1 Comment

Thank you, Eugen! I've also added some details in another answer.
2

Adding some details.

The snippet suggested by @Eugen Covaci actually works:

 .uri(builder -> { return builder .path("/param") .queryParam("p", "{value}") .build(value); }) 

One thing that still remains strange is: why does it happen that writing (seemingly) the same code in a more verbose manner yields a different result? Two forms (pure literal and the one using URI variables) actually use different encoding levels for query parameters, and this looks like a violation of the Principle of least astonishment to me.

It looks like this is caused by legacy problems: earlier, there was a bug: + character was always encoded, although it should not be. Now, the authors fixed the bug, but it created an inconsistency: .queryParam("p", "{value}").build(value) is not the same as .queryParam("p"), value).build().

Looks like one has to just know/remember this.

The full working method code is

private String getValueEchoedThroughQueryParam(String value) { return webTestClient.get() .uri(builder -> { return builder .path("/param") .queryParam("p", "{value}") .build(value); }) .exchange() .expectStatus().is2xxSuccessful() .expectBody(String.class) .returnResult() .getResponseBody(); } 

7 Comments

When using build it will do encoding, when not using build it assumes the value will be already encoded. In that case a + is the encoded value for a whitespace.
@M.Deinum Sorry, I don't understand: how can you not use build() (any of 2)? Without it you have UriBuilder, but you must return URI. Moreover, if doing .queryParam("p", "1+1").build(), it does not encode the plus.
That is what I'm stating. When using path/variable substition it assumes it needs to do encoding, when you don't do path/variable substition it assumes the value is already encoded. So with build(value) you are using path/variable substition, with build() you aren't.
@M.Deinum I see your point. Yes, when you are familiar with the logic of this tool, this behavior seems logical. But when you don't, it does not seem so :) Probably that's just my personal issue, of course. Documentation rules.
The main difference is the use of variable substition or not.
|

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.