Need to be able to specify custom Redirect and Retry Handlers

[rohithbv1991]

Does this functionality exist in the current version? It would be really great if we could have this feature.

[slandelle]

I personally have no usage for non standard HTTP mechanisms, so I won't work on this myself.
Contributions welcome.

[jayantjain93]

Looking to send a separate RedirectHandler to Redirect30xInterceptor via the AsyncHttpClientConfig which returns a request builder, and refactor the class to have a default implementation of the existing redirection builder.
I can contributor this.
@slandelle what do you think about the idea?

[slandelle]

Could you please first explain your use case?

[jayantjain93]

My use case here is that I have a proxy system to which I want to modify the url that it is being redirected to and send specific additional headers.

[slandelle]

So not something that standard user agents such as browsers would support, right?

Then, I'm sorry, but I'll have to decline. I don't want to introduce features that would only be helpful for just a few users who implement hacky use cases.
As you want a custom redirect behavior, I advice you disable followRedirect and implement your own logic in your application.

[jayantjain93]

It might seem that way, however it is more than just a "hacky" use case for limited users. The wide range of use case is also to do with blocking urls from going to unknown domains and the ability for the developer to control that in an easier API friendly way.
Being able to stop circular directs much quicker than waiting for maxRedirect number of hops.
The ability to control the user-agent for different pages, and change the protocol on the redirect.
Give the ability to control to propagate or not propagate the headers.
All of this without needing to maintain the state of the redirects by the developer.

I agree it is not something a standard browser does easily, but that is a limitation rather than a feature. You can change the headers and urls on the browser manually. Most libraries do a redirect/retry handler but none perform as well as this. Not able to handle redirects is a drawback to the lib I feel.
I have already implemented this functionality in a fork of the lib.

I would like you to reconsider if possible. :)

[slandelle]

Again, I'd rather have more information about actual use cases (and not technical implementations).

For example, I agreed on introducing KeepAliveStrategy because it provided a way to detect AWS ALB IP change and then forcefully close the connection instead of offering a doomed connection back to the pool.
The user who requested this feature properly explained the use case, and indeed, there wasn't anything he could do with the way ALB work.

Now, your use case ("I have a proxy system to which I want to modify the url that it is being redirected to and send specific additional headers") seems very specific to he way your private system is implemented.

Generally speaking, I'm not fond of can opener APIs. AHC currently has Request/Response/IoExceptionFilters. Those are buggy (#426, #743, #1094) and no one cares about fixing those, so there's a very good change they will go away in a future release.

Please provide a concrete example.

[rohithbv1991]

@slandelle My use case for this is that the URLs which are received by my system to be hit are first examined and cleaned. This may include removing certain query parameters that we don't want included in the URL, changing the protocol from https to http if the proxy server we are sending the request to does not accept https requests etc.

Without a custom redirect or retry handler, we will be unable to intercept the redirect URL returned by a HTTP 30x response and apply similar transformations/cleanup before the redirect is followed through. So we have control over the initial request but we don't have the same control on redirected or retried requests.

I think this requirement is generic enough that it warrants this feature. There are other async libraries that do provide some such functionality, but we strongly prefer to use this library as it has worked excellently for us so far.

[rohithbv1991]

Also, implementing our own logic for redirect would imply having to take care of things like handling cookies, taking care of all the response headers etc. ourselves, whereas with a custom redirect or retry handler, we can reuse the existing functionality of the library to handle these things.

[nedsociety]

@slandelle Here's our case. Years ago Kubernetes apiserver introduced a random connection drop feature signaled by GOAWAY and we need to implement a retry logic for this. We have no control over the k8s wrapper lib we're using but we do have a control on how it creates an underlying AsyncHttpClient via Dsl. Would that be suffice to motivate this feature request to be done?