Мы переходим с Java 8 на Java 11 и, таким образом, с Spring Boot 1.5.6 на 2.1.2. Мы заметили, что при использовании RestTemplate знак «+» больше не кодируется как «%2B» (изменено SPR-14828). Это было бы нормально, потому что RFC3986 не указывает «+» как зарезервированный символ, но он по-прежнему интерпретируется как «» (пробел) при получении в конечной точке Spring Boot.
У нас есть поисковый запрос, который может принимать необязательные временные метки в качестве параметров запроса. Запрос выглядит примерно так: http://example.com/search?beforeTimestamp=2019-01-21T14:56:50%2B00:00.
Мы не можем понять, как отправить закодированный знак плюс, не закодировав его дважды. Параметр запроса 2019-01-21T14:56:50+00:00 будет интерпретироваться как 2019-01-21T14:56:50 00:00. Если бы мы сами закодировали параметр (2019-01-21T14:56:50%2B00:00), то он был бы получен и интерпретирован как 2019-01-21T14:56:50%252B00:00.
Дополнительным ограничением является то, что мы хотим установить базовый URL-адрес в другом месте при настройке restTemplate, а не там, где выполняется запрос.
В качестве альтернативы, есть ли способ заставить «+» не интерпретироваться конечной точкой как «»?
Я написал короткий пример, демонстрирующий некоторые способы достижения более строгого кодирования с объяснением их недостатков в виде комментариев:
package com.example.clientandserver;
import org.springframework.boot.CommandLineRunner;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.web.client.RestTemplateBuilder;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.client.RestTemplate;
import org.springframework.web.util.DefaultUriBuilderFactory;
import org.springframework.web.util.UriComponentsBuilder;
import org.springframework.web.util.UriUtils;
import java.nio.charset.StandardCharsets;
import java.util.HashMap;
import java.util.Map;
@SpringBootApplication
@RestController
public class ClientAndServerApp implements CommandLineRunner {
public static void main(String[] args) {
SpringApplication.run(ClientAndServerApp.class, args);
}
@Override
public void run(String... args) {
String beforeTimestamp = "2019-01-21T14:56:50+00:00";
// Previously - base url and raw params (encoded automatically).
// This worked in the earlier version of Spring Boot
{
RestTemplate restTemplate = new RestTemplateBuilder()
.rootUri("http://localhost:8080").build();
UriComponentsBuilder b = UriComponentsBuilder.fromPath("/search");
if (beforeTimestamp != null) {
b.queryParam("beforeTimestamp", beforeTimestamp);
}
restTemplate.getForEntity(b.toUriString(), Object.class);
// Received: 2019-01-21T14:56:50 00:00
// Plus sign missing here ^
}
// Option 1 - no base url and encoding the param ourselves.
{
RestTemplate restTemplate = new RestTemplate();
UriComponentsBuilder b = UriComponentsBuilder
.fromHttpUrl("http://localhost:8080/search");
if (beforeTimestamp != null) {
b.queryParam(
"beforeTimestamp",
UriUtils.encode(beforeTimestamp, StandardCharsets.UTF_8)
);
}
restTemplate.getForEntity(
b.build(true).toUri(), Object.class
).getBody();
// Received: 2019-01-21T14:56:50+00:00
}
// Option 2 - with templated base url, query parameter is not optional.
{
RestTemplate restTemplate = new RestTemplateBuilder()
.rootUri("http://localhost:8080")
.uriTemplateHandler(new DefaultUriBuilderFactory())
.build();
Map<String, String> params = new HashMap<>();
params.put("beforeTimestamp", beforeTimestamp);
restTemplate.getForEntity(
"/search?beforeTimestamp={beforeTimestamp}",
Object.class,
params);
// Received: 2019-01-21T14:56:50+00:00
}
}
@GetMapping("/search")
public void search(@RequestParam String beforeTimestamp) {
System.out.println("Received: " + beforeTimestamp);
}
}
+(плюс), как и ожидалось, то принимающая конечная точка Spring Boot не должна пытаться декодировать+(плюс) как ` ` (пробел). К сожалению, это не так из-за, казалось бы, противоречивых стандартов. - person Gregor Eesmaa   schedule 23.05.2019uriTemplateHandler, как вы делаете... но почему? Я не понимаю разницы междуDefaultUriBuilderFactor, который вы используете, иDefaultUriTemplateHandler, который использовался бы иначе. - person Patrick M   schedule 15.01.2020DefaultUriTemplateHandlerкажется устаревшим, но документы указывают, что разница может заключаться в том, что DefaultUriBuilderFactory имеет другое значение по умолчанию для свойства parsePath (от false до true). - person Gregor Eesmaa   schedule 16.01.2020