Do not replace a request factory when creating a new TestRestTemplate with withBasicAuth

[nosan]

See gh-15443

[mbhave]

@nosan Thanks for the PR but I don't think this is how we intended to fix it. We want to avoid using the same reuqestFactory instance when using withBasicAuth. For more details on why, take a look at the commit message here.

I think what we'd want to do instead is use the supplier to create a new instance of the custom requestFactory class and if that fails, fallback to the current behavior. @bclozel WDYT?

[bclozel]

I agree with your analysis @mbhave (and sorry about the late reply, that notification got lost in my inbox).

[mbhave]

Thanks @bclozel.

@nosan Do you want to update the PR to do what I've mentioned above?

[nosan]

@mbhave
Sorry for the long delay, sure, I can update the PR. I am not sure, that I understood you correctly, hence, just to make sure, could you please provide more information about your approach?
Thanks in advance.

[bclozel]

@nosan in the current PR, withBasicAuth is retrieving the current request factory instance from the embedded RestTemplate and reusing it. This line doesn't really change the behavior we're trying to fix.

Several HTTP client libraries are caching the authentication information at the connection pooling level. This means that reusing the same request factory will result in sending the Cookie request header even if the authentication was not meant to be included.

Creating a brand new instance of the configured request factory class (or as Madhura mentioned, falling back to the current behavior in case of problems) should avoid those issues. You can look at the ClientHttpRequestFactorySupplier to check how factories are instantiated.

[nosan]

@mbhave @bclozel Thanks,
I have updated the PR, please let me know if everything is ok or not.

[mbhave]

Thanks again, @nosan. This is now on master along with this additional test.

[nosan]

@mbhave Thanks!