Vincent,
As Roland pointed out, your code does not use HttpClient's native
authentication mechanism. As a result the custom-built authentication
header appears to have been overwritten. This is not an intended
behaviour for which I'll provide a fix. This said, I do recommend that
you use HttpClient authentication mechanism in the future.
As to 2.0 API compatibility, I have already earned myself a few
'non-friends' by my stance on this issue: next release (which was
recently upgraded from 2.1 to 3.0) will not be fully 2.0 API compatible.
Too many things are too badly broken in 2.0 to make any sort of backward
compatibility meaningful.
I strongly urge all the projects that require 2.0 compatibility to stick
to the 2.0 branch until 3.0 makes a first beta. Once we have the new API
agreed, we can think of a migration path which may involve a (1)
compatibility layer, (2) manual code conversion, (3) automatic code
conversion, (4) some combination of 1, 2, and 3.
Oleg
On Mon, 2004-03-15 at 08:09, Vincent Massol wrote:
> 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]
