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=17884.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi Chris
As far as your first point is concerned, just bear with us for a short while. I am
currently working on a patch that should address the problem.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17884
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17158
As far as your second point
Just a quick follow-up to my previous posting. I think there is a solution to the
problem of conflicting authentication realms that would allow us to retain
compatibility with the existing code:
Authenticator class should initially attempt to obtain appropriate credentials using a
key in the
Mike,
I like the idea of a cap on the total number of connections as a
configurable default.
Perhaps HttpClient doesn't need to implicitly perform connection
recycling on idle connections, but how about adding an explicit method
on MultiThreadedConnectionManager that clients can call -
Wouldn't that create a *possible* security risk?
For example, if we store the admin realm on www.apache.org, and then
connect to another site with a realm deliberately named to
[EMAIL PROTECTED], it could be sent the login credentials for the first
site by HttpClient, and then this other site