Oleg, I was aware of the bug writeup, but hadn't noticed the target milestone. I see that the status is still "NEW", so I assume that work hasn't started. I would be happy to donate code and time when this development begins.
-Steve On Tuesday 30 September 2003 09:46 am, Kalnichevski, Oleg wrote: > Steve, > Integrated callbacks are planned for the next release (currently designated > as 2.1) > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10794 > > Oleg > > -----Original Message----- > From: Steve Vaughan [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 30, 2003 3:19 PM > To: Commons HttpClient Project > Subject: Re: Prompting user for authentication? > > > I disagree. It seems counter-intuitive to me that every application that > uses HttpClient should have to provide the same block of code to perform a > function as fundamental as authentication. HttpClient already handles most > authentication, but doesn't currently allow for any form of user > interaction. > > An added benefit of using an integrated callback handler is the additional > information available when authentication is required. Although the code > you provided is able to test the status code for a 401, it does not know > what forms of authentication are available. You could analyze the response > header yourself, but this is already being performed by HttpClient. > > -Steve > > On Tuesday 30 September 2003 08:30 am, Adrian Sutton wrote: > > On 30/09/2003 10:12 PM, "Steve Vaughan" <[EMAIL PROTECTED]> wrote: > > > One of our engineers developed a patch for HttpClient which allows a > > > callback handler to be registered with an HttpClient instance. A > > > registered handler could prompt the user for username/password. When a > > > handler isn't registered, the HttpClient works as it does now. > > > > > > -Steve > > > > The recommended way (at least as far as I'm concerned) of doing this is > > to do it outside of HttpClient since it is in effect outside of what a > > HTTP library should handle. The HTTP library handles talking to the > > server, your code handles displaying the appropriate GUI and dealing with > > errors. So what you do is deal with an unauthorized response like you > > would other recoverable errors (excuse the poor code, Entourage keeps > > capitalising things): > > > > For (int count = 0; count < MAX_ATTEMPTS; count++) { > > GetMethod get = new GetMethod("http://auth.com";); > > int response = httpclient.execute(get); > > if (response >= 200 && response < 300) { > > // Yay it worked. > > } else if (response == 407) { > > // Authorization required (I think 407 is right) > > showAuthDialogAndSetCredentials(theRealm, isNTLM,...); > > // Lets give them unlimited authorization attempts > > count = 0; > > } else if (response == 404) { > > // Aw shucks, we're out of luck. > > } else if (...) { > > // redirect ? > > // Server too busy, try again later > > } > > } > > > > That's the basic idea anyway. I thought everyone used that pattern with > > HttpClient anyway? > > > > Regards, > > > > Adrian Sutton. > > > > ---------------------------------------------- > > Intencha "tomorrow's technology today" > > Ph: 38478913 0422236329 > > Suite 8/29 Oatland Crescent > > Holland Park West 4121 > > Australia QLD > > www.intencha.com > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] For additional > > commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] For additional > commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] For additional > commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
