Hello folks, I've been thinking about authentication and the responsibilities for handling authentication challenges. Right now, http-common and the HttpMethodDirector are explicitly not responsible for dealing with followup requests. http-auth holds code for dealing with authentication challenges, but the responsibility for generating and executing a followup request lies with http-client.
There are two things that bug me about this approach: 1) Someone who wants to use http-common and http-auth cannot do so without either using http-client as well or duplicating code from http-client 2) How does http-auth integrate with http-async? By duplicating code from http-client in http-async? In other words, I don't think our architecture is really componentized at this point. And here is my idea on how to change that: Let's introduce a callback interface in http-common, say "FollowupHandler". A FollowupHandler gets an HttpResponse and the HttpRequest that generated the response to decide whether a followup request is needed. If so, it can also build the new request. Note that the handler does *not* send the followup request, it only generates it. HttpMethodExecutor, after receiving a response, queries the FollowupHandler whether another request needs to be sent. If so, it handles the followup request. That is similar to the error case, where the HttpRequestRetryHandler decides whether the original request should be sent again. FollowupHandlerChain implements FollowupHandler and asks a list of individual handlers until one of them decides that a followup request needs to be sent, or none of them does. So far, the functionality is generic and does not put too much additional complexity in http-common. Now we need some actual followup handlers: - AuthChallengeHandler in http-auth, for handling authentication challenges from proxies and target servers. There is not much point in separating these two cases into different classes. - RedirectHandler (in http-common?) for handling redirects. In http-async, the same interfaces and handler implementations can be used. Remember that http-async is meant to replace HttpMethodDirector for asynchronous communication, and there- fore needs to cover the same functionality. This can be easily achieved using such handlers. The responsibility of http-client will be to collect an appropriate FollowupHandlerChain. With these changes, an application developer can easily combine http-common and http-auth without using http-client. It is also possible to combine http-common, http-async and http-auth. How http-async and http-client can be made to plug and play is a different problem. What do you think? cheers, Roland
