Весенний запрос на загрузку висит там, когда возвращается код состояния 1xx

У меня есть небольшая демонстрация, чтобы играть с настроенным кодом состояния.

Интересная часть – это запрос, который всегда будет висеть там, если статус ниже 200, например, 105, 199 и т. Д. Но работает для любого статуса более 200, например 209, 789 и т. Д.

Реестр кода состояния Http, см. Https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml.

Весенняя загрузка: 1.5.4.RELEASE со встроенным tomcat
Файл spring-configuration-metadata.json не генерируется в IntelliJ Idea для класса Kotlin @ConfigurationProperties
Настройка Jackson для использования SNAKE_CASE «глобально» в Spring Boot 2.0.0.M1
Пользовательский сериализатор Джексона или объект ценности?
Spring Boot: добавление @Transactional создает java.lang.ClassNotFoundException: org.aspectj.util.PartialOrder $ PartialComparable
SpringBoot ArrayIndexOutOfBoundsException MethodParameter.getGenericParameterType

Java: 8

контроллер:

@RestController public class DemoController { @GetMapping("/hello") public ResponseEntity get() { return ResponseEntity.status(105).build(); } }

Может ли кто-нибудь дать мне четкое объяснение?

Я создаю суть здесь: https://gist.github.com/pengisgood/dbea1fcdc45c2bb5809871c7f020b800

Обновить:

Я также создаю небольшую демоверсию, чтобы воспроизвести ее здесь: https://github.com/pengisgood/springboot-customize-status-code

Обновить:

После того, как я запустил curl -v localhost:8080/hello , я могу видеть статус, но ответ не заканчивается. Обратитесь к gif ниже:

результат скручивания

Насколько я могу судить, Spring DispacherServlet обрабатывает разные коды возврата точно так же. Я думаю, что происходит то, что curl просто отключает соединение, потому что ответ находится в диапазоне 1xx .

Эта статья дает хороший код для кодов состояния. Это предложение особенно актуально:

100-199 Коды в 100-х годах являются информационными, что указывает на то, что клиент должен ответить другими действиями.

Если вы запустили curl с помощью --trace вы увидите, что ответ 105 самом деле прибывает:

 curl -v -trace http://localhost:8080/hello Trying ::1... TCP_NODELAY set Connected to localhost (::1) port 8080 (#0) > GET /hello HTTP/1.1 > Host: localhost:8080 > User-Agent: curl/7.54.0 > Accept: */* > < HTTP/1.1 105 < Date: Tue, 19 Sep 2017 18:07:04 GMT ^C

Итак, я думаю, что ответ возвращается, клиент должен ответить каким-то другим действием (но это не так), поэтому похоже, что вещь висела.

Вероятно, настоящий вопрос заключается в том, почему вы пытаетесь вернуть статус 105 и что вы ожидаете?