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]


Reply via email to