Update TestRestTemplate's default cookie handling to be the same as RestTemplate's

[OrangeDog]

This is similar to #27360 (redirect handling).

Because I've moved from Undertow to Jetty as part of Boot 4 migration, I've discovered that different ClientHttpRequestFactory implementations handle cookies differently by default, and there's no property to control it (like spring.http.clients.redirects).

While the factory can be changed with spring.http.clients.imperative.factory, that doesn't help if there isn't one with the behaviour you want on the classpath.

In particular, a TestRestTemplate using HTTP_COMPONENTS will ignore cookies, while one using JETTY will manage a cookie jar internally. This will break some tests that are manually covering sessions and/or assuming independent requests.

[bclozel]

Sorry but I don't understand the goal of this issue.

You seem to point out that:

• Undertow and Jetty don't behave the same (I don't see the connection here)
• spring.http.clients.redirects helps with configuring the behavior for redirects
• spring.http.clients.imperative.factory controls which HTTP library is being used
• HttpComponents and Jetty clients don't handle cookies the same way
• tests that are manually covering sessions and/or assuming independent requests this seems to ask for both supporting cookies persistence between requests, and ignore cookies completely. I'm confused.

HttpComponents HttpClient does support cookies in general, maybe not the same way as Jetty, or maybe it's not just configured the same way.

Can we take a step back? Before considering a property, could we consider the problem? What are you trying to achieve? Why was it working with Undertow and it's not working anymore with Jetty? Can you share a minimal sample showing the behavior you are seeing with TestRestTemplate and describe what you are expecting?

Thanks

[OrangeDog]

As with the linked issue, the general idea is that the (Test)RestTemplate/Client should behave the same by default regardless of the client factory.

it's not just configured the same way

Exactly. And there's no longer any way to configure it, because withRequestFactorySettings was removed.

this seems to ask for both supporting cookies persistence between requests, and ignore cookies completely

No, it's asking for it to be at minimum configurable, and at best have a consistent default.

Why was it working with Undertow and it's not working anymore with Jetty?

Because now Jetty is on the classpath, changing the default factory to JETTY in some cases.

Can you share a minimal sample showing the behavior you are seeing with TestRestTemplate

@SpringBootTest
@AutoConfigureTestRestTemplate
public class Test {
    @Autowired TestRestTemplate restTemplate;
    @Test
    public void test() {
        var response1 = restTemplate.getForEntity("/", String.class);
        assertTrue(response1.getHeaders().containsHeader(HttpHeaders.SET_COOKIE));
  
        var response2 = restTemplate.getForEntity("/", String.class);
        assertTrue(response2.getHeaders().containsHeader(HttpHeaders.SET_COOKIE));
    }
}

Assuming the application is configured to use session cookies, this test passes with SIMPLE, JDK, and HTTP_COMPONENTS but fails with JETTY.

[OrangeDog]

Outside of testing, I think most people would expect REST client requests from a Spring Boot application to be stateless, but it appears that if you have Jetty on the classpath then they might not be.

[snicoll]

Please share a sample, not some code in test with "Assuming that". We don't want to assume anything and would like to work based on something that represents the problem you've described.

[bclozel]

As with the linked issue, the general idea is that the (Test)RestTemplate/Client should behave the same by default regardless of the client factory.

From my perspective, this is not the goal behind RestTemplate and RestClient. The intent is to provide a common programming model and leverage different HTTP clients with different opinions and features. If a strictly common behavior was the main goal, we would only support the JDK HTTP client.

While we can provide configuration properties, I don't think we should try to erase the differences between clients as this is likely to deceive developers and break in surprising ways.

[OrangeDog]

Would you not be surprised that changing the servlet container to or from Jetty changes the semantics of the REST client?