hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@pivolis.com>
Subject FW: [Cactus] Gump build failures for the past 2 weeks
Date Mon, 15 Mar 2004 08:48:20 GMT
Hi gumpmeisters,

How do we handle this?

Do we force Gumpy to use the 2.0 branch from httpclient?

Thanks
-Vincent

> -----Original Message-----
> From: Oleg Kalnichevski [mailto:olegk@apache.org]
> Sent: 15 March 2004 08:59
> To: Commons HttpClient Project
> Subject: RE: [Cactus] Gump build failures for the past 2 weeks
> 
> 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:olegk@apache.org]
> > > 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:vmassol@pivolis.com]
> > > > > Sent: 15 March 2004 00:30
> > > > > To: 'Commons HttpClient Project'
> > > > > Cc: gump@jakarta.apache.org
> > > > > 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: commons-httpclient-dev-
> unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-httpclient-dev-
> help@jakarta.apache.org
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-
> unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-
> help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org


Mime
View raw message