Thank very much Roland. I've made the change and it seems to be working (although it requires commons-codec after version 2.0 of httpclient).
As httpclient is only an internal library of Cactus we do not want to put too much unnecessary strain on Cactus users (it does not buy users anything that we move to 3.x). Thus we'll probably be staying on the 2.x branch (which does not require commons-codec). Thanks! -Vincent > -----Original Message----- > From: Roland Weber [mailto:[EMAIL PROTECTED] > Sent: 15 March 2004 08:41 > To: Commons HttpClient Project > Subject: RE: [Cactus] Gump build failures for the past 2 weeks > > Hello Vincent, > > the code should not add an Authorization header. > HttpClient does that automatically, and probably > removes the one you set in the process. Instead: > > - store uid/pwd in the HttpState as default credential > - enable preemptive authentication on the HttpMethod > > The correct Authorization header will then be > generated by the HttpClient. You don't have to > care about the header format and base64 > encoding in the application. > > cheers, > Roland > > > > > > > "Vincent Massol" <[EMAIL PROTECTED]> > 15.03.2004 08:09 > Please respond to "Commons HttpClient Project" > > To: "'Commons HttpClient Project'" > <[EMAIL PROTECTED]> > cc: "'Cactus Developers List'" <[EMAIL PROTECTED]> > Subject: RE: [Cactus] Gump build failures for the past 2 > weeks > > > Hi Oleg, > > Thanks very much for your help. Here's the code that adds basic > authentication (by adding authorization HTTP header): > > public void configure(WebRequest theRequest, > Configuration theConfiguration) > { > // According to HTTP 1.0 Spec: > // basic-credentials = "Basic" SP basic-cookie > // basic-cookie = <base64 encoding of userid-password, > // except not limited to 76 char/line> > // userid-password = [ token ] ":" *TEXT > // > // see setName and setPassword for details of token and TEXT > String basicCookie = getName() + ":" + getPassword(); > String basicCredentials = "Basic " > + new String(base64Encode(basicCookie.getBytes())); > > theRequest.addHeader("Authorization", basicCredentials); > } > > Then, we use HttpClient to send the request: > > [...] > // Add the cookies > HttpState state = CookieUtil.createHttpState(theRequest, url); > > // Open the connection and get the result > HttpClient client = new HttpClient(); > HostConfiguration hostConfiguration = new HostConfiguration(); > hostConfiguration.setHost(url.getHost(), url.getPort(), > Protocol.getProtocol(url.getProtocol())); > client.setState(state); > client.executeMethod(hostConfiguration, this.method); > > // Wrap the HttpClient method in a java.net.HttpURLConnection > object > return new org.apache.commons.httpclient.util.HttpURLConnection( > this.method, url); > > > Let me know if you need more details to understand it. > > Do I have to assume that these changes in httpclient are not > backward-compatible and there's no compatibility layer, right? Thus if > Cactus moves to 2.1-dev, we'll need to deliver cactus with httpclient > 2.1-dev bundled. Thus there is a risk that httpclient 2.1-dev is not > stable at that point (we'll be releasing a new version of Cactus next > week). Of course, we could build a compatibility layer in Cactus itself > to support both httpclient 2.0 and 2.1-dev. Frankly, I think it makes > more sense for httpclient to do this. It could get dropped once 2.1 > final is out. It would really be good if 2.1 was backward compatible (it > could of course introduce new APIs). Lots of persons are using > httpclient and breaking an API is not a very good migration path... :-) > > What do you suggest? > > Thanks > -Vincent > > > -----Original Message----- > > From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] > > Sent: 15 March 2004 00:52 > > To: Commons HttpClient Project > > Subject: RE: [Cactus] Gump build failures for the past 2 weeks > > > > Vincent, > > >From the cursory examination the problem appears to have been caused > by > > HttpClient not finding the required credentials. The way credentials > are > > set in the HTTP state has changed. Could you please give the code > > snippet containing calls to HttpState#setCredentials() method(s)? This > > method may be the cause of the problem. > > > > More tomorrow > > > > Oleg > > > > > > On Mon, 2004-03-15 at 00:40, Vincent Massol wrote: > > > It seems the attachment was stripped. I've uploaded it on: > > > > > > http://cvs.apache.org/~vmassol/test_client.log > > > > > > Thanks > > > -Vincent > > > > > > > -----Original Message----- > > > > From: Vincent Massol [mailto:[EMAIL PROTECTED] > > > > Sent: 15 March 2004 00:30 > > > > To: 'Commons HttpClient Project' > > > > Cc: [EMAIL PROTECTED] > > > > Subject: [Cactus] Gump build failures for the past 2 weeks > > > > > > > > Hi guys, > > > > > > > > I've finally tracked down the Cactus gump build problem we've been > > > > having for the past 2 weeks. It appears to be caused by some > change in > > > > commons-httpclient. > > > > > > > > The build is working fine with version 2.0 and failing on some > > > > authentication code with a commons-httpclient built from CVS HEAD. > > > > > > > > I'm attaching the cactus log file (which contains httpclient logs) > in > > > > case it helps. > > > > > > > > Any idea what can have changed? > > > > > > > > Thanks > > > > -Vincent > > > --------------------------------------------------------------------- > 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]
