此提交引入了对 ClientHttpRequestFactories 中的 JdkClientHttpRequestFactory 的支持。
笔记：
JdkClientHttpRequestFactory则优先使用 。结果，几个预期的测试失败了，并且由于在这种情况下无法使用，我不确定如何继续。也许需要一个新的注释？SimpleClientHttpRequestFactoryjava.net.httpSimpleClientHttpRequestFactory@ClassPathExclusions@ModuleExclusions我已经打开了https://github.com/spring-projects/spring-boot/issues/36120，以便@ClassPathExclusions可以用于从类路径中排除单个包以及整个 jar 。
这有可能进入启动 3.2.0-M1 吗？
@wilkinsona谢谢，使用ClassPathExclusions.packages所有测试都是绿色的。
smoketest.actuator.ui.SampleActuatorUiApplicationTests.testCss()这些改变失败了。这是测试：
以前它使用SimpleClientHttpRequestFactory但现在它使用JdkClientHttpRequestFactory.与前者不同，后者不会自动遵循重定向。该请求由 Spring Security 重定向/login，这意味着状态代码断言现在失败。
鉴于任何SimpleClientHttpRequestFactory通过启动自动配置使用的人现在很可能会使用它JdkClientHttpRequestFactory，我认为这种行为变化可能会在人们升级时导致问题。我想知道是否可以将 JDK 的 HTTP 客户端配置为默认遵循重定向。
请参阅https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.Builder.html#followRedirects(java.net.http.HttpClient .重定向）。默认是NEVER，您认为我们应该在框架中更改它以提供与其他请求工厂更好的兼容性吗？
是的，我想是的。具体来说，与SimpleClientHttpRequestFactory启用重定向（针对请求）的行为保持一致GET对我来说是一个好主意，因为一旦这些更改合并，许多用户SimpleClientHttpRequestFactory将成为用户。JdkClientHttpRequestFactory
HttpClient现在创建的默认JdkClientHttpRequestFactory遵循重定向，请参阅https://github.com/spring-projects/spring-framework/commit/7c37f4bc5112d3f6cbb77a02c96b427f032d656c
@poutsma您认为还值得添加框架测试吗？如果SampleActuatorUiApplicationTests这是唯一能捕捉到这一点的东西，那么可能很难捕捉到回归。
感谢@poutsma 的重定向更改。不幸的是，我现在遇到了另一个与重定向相关的问题。这次就涉及到set-cookie头部了。
我们有一个测试向 发出POST请求/login。它收到一个重定向响应，其中包含以下两个标头：
location: http://localhost:53640/
set-cookie: SESSION=ZGYzMDhhM2ItOTk4Yy00OThkLTg2ZDktM2U1MmFiNDA2YmI3; Path=/; HttpOnly; SameSite=Lax与仅遵循请求重定向的简单客户端不同GET，此重定向会自动遵循并向GET发出请求http://localhost:53640/。由于没有配置 cookie 管理器，因此不会cookie发送标头。HttpClient对此请求的响应GET包含以下标头：
location: http://localhost:53640/login
set-cookie: SESSION=NTI3YTUwMDgtMjIyNS00OTI1LWFkOWUtYTM3ZjVjYzkxNGFm; Path=/; HttpOnly; SameSite=Lax也遵循此重定向，因此GET现在向 发出请求http://localhost:53640/login。再次，没有cookie发送标头。对此的响应是带有 HTML 登录页面的 200，set-cookie响应中没有标头。以下重定向会阻止测试获取set-cookie响应原始请求而发送的标头POST，从而导致无法使用当前配置进行登录HttpClient。
在我看来，我们有两个相互竞争的要求，无法同时满足。为了匹配简单请求工厂的行为，我们需要遵循重定向，但仅限于GET请求，而新的HttpClient.这让我们在 Boot 中陷入了尴尬的境地。
如果我们引入JdkClientHttpRequestFactory对 的支持SimpleClientHttpRequestFactory，我认为这对于当前使用SimpleClientHttpRequestFactory.如果我们愿意SimpleClientHttpRequestFactory，JdkClientHttpRequestFactory自动检测将永远不会选择后者，因为SimpleClientHttpRequestFactory所需的类将始终存在。感觉这里没有一个好的答案。使用 cookie 管理器进行配置HttpClient可能会有所帮助，但我认为这并不能完全解决问题。
从框架的角度来看，我不太愿意更改更多默认值JdkClientHttpRequestFactory
有不同的默认值有意义吗？SimpleClientHttpRequestFactory为了RestTemplate，但是JdkClientHttpRequestFactory为了RestClient？
从框架的角度来看，我不太愿意更改
JdkClientHttpRequestFactory.
明白了。如果可以的话，我更愿意与引导中的框架默认值保持一致，我想出于类似的原因。
有不同的默认值有意义吗？
SimpleClientHttpRequestFactory为了RestTemplate，但是JdkClientHttpRequestFactory为了RestClient？
我宁愿不这样做。我认为这可能会令人困惑，这意味着ClientHttpRequestFactories需要根据调用者的目的采取不同的行为。
如果这归结为在HttpClient所有默认值和HttpClient重定向NORMAL策略之间进行直接选择，我认为前者稍微好一些。对我来说，这比上面描述的问题要好一些，Set-Cookie当对 的响应POST自动重定向时，对标头的访问会丢失。更客观地说，它也让我们重新与 JDK 的默认值完全一致。我发现当将一个问题替换为另一个问题而不是解决/不引起任何一个问题时，更改这些默认值更难以证明其合理性。
SimpleClientHttpRequestFactory对于那些通过自动检测使用的人来说，这会给我们带来启动问题。它们更改为JdkClientHttpRequestFactory可能会导致一些破坏，但也许我们可以通过发行说明解决这个问题。我觉得这是目前最不糟糕的选择。
如果这归结为在
HttpClient所有默认值和HttpClient重定向NORMAL策略之间进行直接选择，我认为前者稍微好一些。对我来说，这比上面描述的问题要好一些，Set-Cookie当对 的响应POST自动重定向时，对标头的访问会丢失。更客观地说，它也让我们重新与 JDK 的默认值完全一致。我发现当将一个问题替换为另一个问题而不是解决/不引起任何一个问题时，更改这些默认值更难以证明其合理性。
同意。我必须承认，我已经对更改默认重定向策略感到有点烦恼，因为我认为我们不会更改任何其他 http 客户端中的默认设置。ClientHttpRequestFactory类并不意味着可以直接替换，它们都有自己的默认值。从我们这边改变这些本质上是说：“我们比 http 客户端库的开发人员更了解”，这很好，但确实要求我们跟上所有最新的安全更新和所述客户端库的其他最佳实践。我宁愿坚持使用默认值。
SimpleClientHttpRequestFactory对于那些通过自动检测使用的人来说，这会给我们带来启动问题。它们更改为JdkClientHttpRequestFactory可能会导致一些破坏，但也许我们可以通过发行说明解决这个问题。我觉得这是目前最不糟糕的选择。
同意。
Boot 团队今天对此进行了一些讨论，并决定我们认为目前最好的选择是添加支持，JdkClientHttpRequestFactory而不使其成为自动检测的一部分。这将使人们能够轻松选择使用它，而无需被迫进行更改。我打开了https://github.com/spring-projects/spring-boot/issues/36266以便更轻松地覆盖自动检测。实现后，我们可以添加JdkClientHttpRequestFactory自动检测，因为它很容易被覆盖。