DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10794>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10794 User interaction for authentication ------- Additional Comments From [EMAIL PROTECTED] 2004-01-29 17:03 ------- Darn. It looks like we all agree to disagree. Let me try to find a common ground, unless we want to find ourselves in a classical design impasse. (1) Odi, your idea to abstract away the credentials persistence stuff is great, but possibly it is too radical for the 3.0. Let us revisit this problem in the course of 4.0 API redesign. Can we stick to the concept of HttpState being a cache of objects representing HTTP session state for the 3.x release? Let's face it there are uglier things in HttpClient 2.0 than HttpState class (2) HttpState (as a cache) in its present form does not seem to be the ideal placeholder for the credential callbacks. Can we all live with HttpParams as an alternative for the 3.x release. Again, it may change in the 4.0 (3) Reasons for keeping proxy and host credentials distinct are purely emotional / perceptional. Usually users could not care less if they are authenticating against a proxy or target host as long as they are presented with a sane name for the authentication realm. For instance, IE 5.x does not differentiate between proxy & host authentication. Getting rid of separate repository for proxy credentials will GREATLY simplify authentication code in HttpMethodDirector. I think this is well worth it. Besides, may I suggest to have a boolean flag (proxy yes|no) added to CredentialsCallback interface to keep everyone happy? Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
