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:[EMAIL PROTECTED] > 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:[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: commons-httpclient-dev- > [EMAIL PROTECTED] > > For additional commands, e-mail: commons-httpclient-dev- > [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: commons-httpclient-dev- > [EMAIL PROTECTED] > For additional commands, e-mail: commons-httpclient-dev- > [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
