You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Vincent Massol <vm...@pivolis.com> on 2004/03/15 00:29:46 UTC
[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
Re: [Cactus] Gump build failures for the past 2 weeks
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2004-03-15 at 00:29, Vincent Massol wrote:
> 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?
>
Frankly, everything has changed as far as authentication code is
concerned. The complete authentication logic has been redesigned to
address the architectural limitations present in HttpClient 2.0. It's
already late here. I'll look into the problem tomorrow
Cheers
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
RE: [Cactus] Gump build failures for the past 2 weeks
Posted by Oleg Kalnichevski <ol...@apache.org>.
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
RE: [Cactus] Gump build failures for the past 2 weeks
Posted by Vincent Massol <vm...@pivolis.com>.
Hi Roland,
Thanks. I'll try this today. Do you know if httpclient 2.0 final is also
working like this or is this something new from 2.1-dev?
Thanks
-Vincent
> -----Original Message-----
> From: Roland Weber [mailto:ROLWEBER@de.ibm.com]
> 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" <vm...@pivolis.com>
> 15.03.2004 08:09
> Please respond to "Commons HttpClient Project"
>
> To: "'Commons HttpClient Project'"
> <co...@jakarta.apache.org>
> cc: "'Cactus Developers List'"
<ca...@jakarta.apache.org>
> 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: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
RE: [Cactus] Gump build failures for the past 2 weeks
Posted by Vincent Massol <vm...@pivolis.com>.
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:ROLWEBER@de.ibm.com]
> 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" <vm...@pivolis.com>
> 15.03.2004 08:09
> Please respond to "Commons HttpClient Project"
>
> To: "'Commons HttpClient Project'"
> <co...@jakarta.apache.org>
> cc: "'Cactus Developers List'"
<ca...@jakarta.apache.org>
> 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: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
RE: [Cactus] Gump build failures for the past 2 weeks
Posted by Roland Weber <RO...@de.ibm.com>.
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" <vm...@pivolis.com>
15.03.2004 08:09
Please respond to "Commons HttpClient Project"
To: "'Commons HttpClient Project'"
<co...@jakarta.apache.org>
cc: "'Cactus Developers List'" <ca...@jakarta.apache.org>
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: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
RE: [Cactus] Gump build failures for the past 2 weeks
Posted by Vincent Massol <vm...@pivolis.com>.
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
RE: [Cactus] Gump build failures for the past 2 weeks
Posted by Vincent Massol <vm...@pivolis.com>.
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: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: [Cactus] Gump build failures for the past 2 weeks
Posted by Oleg Kalnichevski <ol...@apache.org>.
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
RE: [Cactus] Gump build failures for the past 2 weeks
Posted by Vincent Massol <vm...@pivolis.com>.
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