When I thought about this my initial idea was adding just one retriable configuration for everything. So this method would be getRetriableHttpClient() and the retry options are just defined in this factory as options (similar to other options for proxy or similar in the normal client). This would simplify the configuration and would remove the need to add the UI options for the places that we decide to use the retry. This way adding this to CRL for example is just changing the method without adding any new configuration options. Besides it avoids a lot of the burden in this PR. WDYT?

The same configuration should be used for both clients, but the retriable one adds the specifics for the retry. There are only two clients defined that are initialize only once each. By default (if no retry is configured) the same client is used.

ahh i can see how this would be simpler and more consistent. the only downside i can think of here is less flexibility in how retries would be approached. I'm open to this implementation if that is what you all would prefer.

@chance-coleman has a point here in my opinion. Depending on the area of the code, we may want to use different setting. In other words, what will work correctly for OCSP might not be a good fit for Identity Providers or other functionalities.

Yep, this is just a matter of what we prefer. Let's see what other people think aboy this.

+1 for just getRetriableHttpClient() . If we ever need different configuration for different "use-cases" of HTTP client, we can add new method if needed.

I can imagine that we may want different configurations for different use-cases, however this might mean also different configurations for other aspects than just retry configuration. For more flexibility, maybe the best is to have the method like:

            @Override
            public CloseableHttpClient getHttpClient(String context) {

where context is for example something like "ocsp" or "facebook-idp" . Then in the configuration of Http-client provider, we can add namespaces for various configuration options. For example we can have ocsp--proxy-mappings if we want to have different proxy-mappings configuration for the case when HTTP client is called in the context of "ocsp"
. This will also allow to have different retry configurations for "ocsp" and different for other things. The Config.Scope has some support for namespaces in itself AFAIK.

I do not insist on this, but would prefer something like this instead of introducing getRetriableHttpClient(RetryConfig) , which IMO does not have much flexibility and at the same time, it is not used anywhere right now.

The getRetriableHttpClient() is also less ideal than namespaces IMO, but maybe good compromise if others prefer this instead of introducing "namespaces" .

@mposolda i can see the benefits in this approach. The context-based approach is more flexible and maintainable in the long run. The main trade-off is slightly more complex configuration. It's definitely a balance and some preference, ultimately it's your codebase so i'm happy to make changes either way!

I really don't like this sleep. What is the reason for this? Normal DefaultHttpRequestRetryHandler is not enough for you?

Hmmm good question, my understanding was that Apache HttpClient 4.5.14 DefaultHttpRequestRetryHandler does not implement any backoff or delay between retries. The retry logic simply checks if we should retry and immediately returns the decision.

The sleep in the code was necessary to implement the exponential backoff with jitter functionality. Without it, the retries would happen in rapid succession, which i believe to be a more robust solution, although more complex.

There is also ServiceUnavailableRetryStrategy . Could not that one be used instead of implementing the retry logic in our own codebase? For example see the 2nd post from https://stackoverflow.com/questions/48541329/timeout-between-request-retries-apache-httpclient .

While ServiceUnavailableRetryStrategy is great for fine-tuning HTTP error responses, it's limited to HTTP-layer issues and doesn't handle lower-level network problems. Our current solution handles the full spectrum of failures; from TLS errors and dropped connections to server errors, in one straightforward implementation. This single-point approach ensures reliable retries whether the issue is in the network stack or the HTTP layer, without the complexity of managing multiple retry strategies.

There is also ServiceUnavailableRetryStrategy . Could not that one be used instead of implementing the retry logic in our own codebase? For example see the 2nd post from https://stackoverflow.com/questions/48541329/timeout-between-request-retries-apache-httpclient .

+1 for just getRetriableHttpClient() . If we ever need different configuration for different "use-cases" of HTTP client, we can add new method if needed.

I can imagine that we may want different configurations for different use-cases, however this might mean also different configurations for other aspects than just retry configuration. For more flexibility, maybe the best is to have the method like:

            @Override
            public CloseableHttpClient getHttpClient(String context) {

where context is for example something like "ocsp" or "facebook-idp" . Then in the configuration of Http-client provider, we can add namespaces for various configuration options. For example we can have ocsp--proxy-mappings if we want to have different proxy-mappings configuration for the case when HTTP client is called in the context of "ocsp"
. This will also allow to have different retry configurations for "ocsp" and different for other things. The Config.Scope has some support for namespaces in itself AFAIK.

I do not insist on this, but would prefer something like this instead of introducing getRetriableHttpClient(RetryConfig) , which IMO does not have much flexibility and at the same time, it is not used anywhere right now.

The getRetriableHttpClient() is also less ideal than namespaces IMO, but maybe good compromise if others prefer this instead of introducing "namespaces" .

I am not sure why those configuration options have prefix http-client here? Other config options of the provider do not have this prefix.

Also there is one confusing aspect: When someone reads the documentation of this provider, he would see http-client-default-max-retries configured to 3, which imply that this is used by default by HTTP client. But AFAIK, this is used just if getRetriableHttpClient() is called right? By default, the getHttpClient() or other methods do not use this retry configuration at all and requests are not retried. Which is not clear from this docs...

Might be better if we have something like .name("default-max-retries") (which would be 0 by default and hence disabled retries) and .name("ocsp--default-max-retries") (which would be 3 and hence enabled retries for OCSP by default). I proposed in the other comment to use "namespaces" for the configurations. This will be likely harder to implement, but seems to me like more clear configuration.

I would add something around the fact that outgoing request retries should not exceed the timeout for incoming requests

I've added a callout like this:

IMPORTANT: Do not let outgoing retry duration exceed the caller’s timeout. Otherwise, the caller may time out and see an error while {project_name} continues retrying in the background.