You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Riad Souissi <ri...@yahoo.com> on 2005/07/22 16:21:19 UTC
Problem with "Unbuffered entity enclosing request can not be repeated" when sending a large stream
Hi
- This issue appeared with version3 RC3 (I had no problem with RC1 and possibly RC2).
- I am sending a large file through HTTPClient. Since it is large, I avoid using buffering (stream
size is known, not equal to -1 or -2).
- When an error happen which involves the RetryHandler (derived from
DefaultHttpMethodRetryHandler), I used to reset the InputStream to position zero (either using
InputStream.mark(0) in the init phase then reset() or
((FileInputStream)stream).getChannel().position(0) in JDK 1.4). This way, the retry mechanism will
reuse a properly initialized stream from its beginning.
This used to work, however, with RC3, it seems from the source code that InputStreamRequestEntity
is not repeatable anymore (which I can understand in case a stream cannot be reset, but in many
case, may be most cases, it can be reset and reused).
This causes the "Unbuffered entity enclosing request can not be repeated" error and faisl the HTTP
call.
This is the java stacktrace:
org.apache.commons.httpclient.ProtocolException: Unbuffered entity enclosing request can not be
repeated.
at
org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:483)
at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:1973)
at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:993)
at
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:393)
at
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:168)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:346)
I wanted to rely fully on the RetryHandler of the HTTPClient rather than add another layer of
retrying on top of it, which I would like to avoid.
Do you guys have a nice solution ?
I would suggest that you make a method in InputStreamRequestEntity to force it to be repeatable if
the developer knows he can reuse and reset the stream. Is that possible ?
Thanks
riad
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Problem with V3 RC3 and HTTPClient.getHostConfiguration().setHost("localhost", "443", sslProtocol) not working anymore
Posted by Michael Becke <mb...@gmail.com>.
If you're wondering how to make HttpClient resolve which Protocol to
use based upon host and port, it is not possible. This is something
you will have to handle manually.
Mike
On 7/23/05, Riad Souissi <ri...@yahoo.com> wrote:
> Thanks Oleg, it worked. I always used obsolute URLs before...
>
> By the way, in case of absolute URLs, how can I register a protocol but relative to the protocol
> (https), port and hostname ?
>
> Thanks again,
> riad
>
>
> --- Oleg Kalnichevski <ol...@apache.org> wrote:
>
> > Riad,
> >
> > Does your postmethod target a relative URL, and not an absolute one? If
> > it does not, make sure it does
> >
> > sslProtocol = new Protocol("https", factory, "443");
> > HostConfiguration hostConf = new HostConfiguration();
> > hostConf.setHost("localhost", 443, sslProtocol)
> >
> > // Will pick up sslProtocol from hostConf
> > PostMethod postmethod = new PostMethod("/relative");
> > client.executeMethod(hostConf, postmethod)
> >
> > // Will ALWAYS pick up the default Protocol (the one registered using
> > // Protocol#registerProtocol
> > // hostConf will have no effect because the host and protocol are
> > // given in the URL itself
> > PostMethod postmethod = new PostMethod("https://localhost/absolute");
> > client.executeMethod(hostConf, postmethod);
> >
> > Oleg
> >
> > On Fri, 2005-07-22 at 11:33 -0700, Riad Souissi wrote:
> > > Hi again,
> > >
> > > I forgot to mention something:
> > >
> > > I am not using :
> > > - client.getHostConfiguration().setHost("localhost", 443, sslProtocol)
> > > I use instead:
> > > - hostConf.setHost("localhost", 443, sslProtocol)
> > > - client.executeMethod(hostConf, postmethod)
> > >
> > > But it is the same, it gives the same problem
> > >
> > > riad
> > >
> > >
> > > --- Riad Souissi <ri...@yahoo.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > I had the following code which used to work from Beta1 to RC2 but stopped to work in RC3:
> > > >
> > > > HTTPClient client = ...
> > > > SecureProtocolSocketFactory factory = ...
> > > > sslProtocol = new Protocol("https", factory, "443");
> > > > client.getHostConfiguration().setHost("localhost", "443", sslProtocol);
> > > >
> > > > After I moved to RC3, I always have this java error:
> > > >
> > > > avax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: No trusted
> > > > certificate found
> > > > at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(DashoA6275)
> > > > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> > > > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> > > > at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)
> > > > at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)
> > > > at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(DashoA6275)
> > > > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> > > > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA6275)
> > > > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> > > > at com.sun.net.ssl.internal.ssl.AppOutputStream.write(DashoA6275)
> > > > at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:66)
> > > > at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:124)
> > > > at
> > > >
> > >
> >
> org.apache.commons.httpclient.methods.StringRequestEntity.writeRequest(StringRequestEntity.java:140)
> > > > at
> > > >
> > >
> >
> org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:495)
> > > > at
> > org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:1973)
> > > > at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:993)
> > > > at
> > > >
> > org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:393)
> > > > at
> > > > org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:168)
> > > > at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)
> > > > at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:346)
> > > >
> > > > As if it does not use the custom SecureProtocolSocketFactory anymore (and from the traces in
> > my
> > > > custom SecureProtocolSocketFactory, it never gets called)
> > > > Then for testing, I changed the last line of the code to: Protocol.registerProtocol("https",
> > > > sslProtocol)
> > > >
> > > > It still did not work, but for a different reason which I could not explain:
> > > >
> > > > javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Untrusted
> > Server
> > > > Certificate Chain
> > > > at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(DashoA6275)
> > > > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> > > > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> > > > at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)
> > > > at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)
> > > > at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(DashoA6275)
> > > > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> > > > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA6275)
> > > > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> > > > at com.sun.net.ssl.internal.ssl.AppOutputStream.write(DashoA6275)
> > > > at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:66)
> > > > at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:124)
> > > > at
> > > >
> > >
> >
> org.apache.commons.httpclient.methods.StringRequestEntity.writeRequest(StringRequestEntity.java:140)
> > > > at
> > > >
> > >
> >
> org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:495)
> > > > at
> > org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:1973)
> > > > at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:993)
> > > > at
> > > >
> > org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:393)
> > > > at
> > > > org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:168)
> > > > at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)
> > > > at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:346)
> > > >
> > > > My custom SSLProtocol gets invoked this time but for some reason, the method
> > > > defaultTrustManager.isServerTrusted(certificates) always returns false eventhough it is
> > exactly
> > > > the same which gets invoked in RC2 with the HostConfiguration.
> > > > I can also see from my own logs that the same server certificates are sent to the HTTPClient
> > but
> > > > this time they are not recognized !
> > > >
> > > > By the way, even if Protocol.registerProtocol(), I cannot use it because it overrides all
> > the
> > > > SSL
> > > > protocols at the level of the port. but in my custom client, I have different HTTPClients
> > > > connecting to the same port but on different hosts.
> > > >
> > > > Any idea ?
> > > >
> > > > Thanks
> > > > riad
> > > >
> > > > __________________________________________________
> > > > Do You Yahoo!?
> > > > Tired of spam? Yahoo! Mail has the best spam protection around
> > > > http://mail.yahoo.com
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> > > >
> > > >
> > >
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Tired of spam? Yahoo! Mail has the best spam protection around
> > > http://mail.yahoo.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> >
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Problem with V3 RC3 and HTTPClient.getHostConfiguration().setHost("localhost", "443", sslProtocol) not working anymore
Posted by Riad Souissi <ri...@yahoo.com>.
Thanks Oleg, it worked. I always used obsolute URLs before...
By the way, in case of absolute URLs, how can I register a protocol but relative to the protocol
(https), port and hostname ?
Thanks again,
riad
--- Oleg Kalnichevski <ol...@apache.org> wrote:
> Riad,
>
> Does your postmethod target a relative URL, and not an absolute one? If
> it does not, make sure it does
>
> sslProtocol = new Protocol("https", factory, "443");
> HostConfiguration hostConf = new HostConfiguration();
> hostConf.setHost("localhost", 443, sslProtocol)
>
> // Will pick up sslProtocol from hostConf
> PostMethod postmethod = new PostMethod("/relative");
> client.executeMethod(hostConf, postmethod)
>
> // Will ALWAYS pick up the default Protocol (the one registered using
> // Protocol#registerProtocol
> // hostConf will have no effect because the host and protocol are
> // given in the URL itself
> PostMethod postmethod = new PostMethod("https://localhost/absolute");
> client.executeMethod(hostConf, postmethod);
>
> Oleg
>
> On Fri, 2005-07-22 at 11:33 -0700, Riad Souissi wrote:
> > Hi again,
> >
> > I forgot to mention something:
> >
> > I am not using :
> > - client.getHostConfiguration().setHost("localhost", 443, sslProtocol)
> > I use instead:
> > - hostConf.setHost("localhost", 443, sslProtocol)
> > - client.executeMethod(hostConf, postmethod)
> >
> > But it is the same, it gives the same problem
> >
> > riad
> >
> >
> > --- Riad Souissi <ri...@yahoo.com> wrote:
> >
> > > Hi,
> > >
> > > I had the following code which used to work from Beta1 to RC2 but stopped to work in RC3:
> > >
> > > HTTPClient client = ...
> > > SecureProtocolSocketFactory factory = ...
> > > sslProtocol = new Protocol("https", factory, "443");
> > > client.getHostConfiguration().setHost("localhost", "443", sslProtocol);
> > >
> > > After I moved to RC3, I always have this java error:
> > >
> > > avax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: No trusted
> > > certificate found
> > > at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(DashoA6275)
> > > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> > > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> > > at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)
> > > at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)
> > > at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(DashoA6275)
> > > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> > > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA6275)
> > > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> > > at com.sun.net.ssl.internal.ssl.AppOutputStream.write(DashoA6275)
> > > at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:66)
> > > at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:124)
> > > at
> > >
> >
>
org.apache.commons.httpclient.methods.StringRequestEntity.writeRequest(StringRequestEntity.java:140)
> > > at
> > >
> >
>
org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:495)
> > > at
> org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:1973)
> > > at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:993)
> > > at
> > >
> org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:393)
> > > at
> > > org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:168)
> > > at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)
> > > at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:346)
> > >
> > > As if it does not use the custom SecureProtocolSocketFactory anymore (and from the traces in
> my
> > > custom SecureProtocolSocketFactory, it never gets called)
> > > Then for testing, I changed the last line of the code to: Protocol.registerProtocol("https",
> > > sslProtocol)
> > >
> > > It still did not work, but for a different reason which I could not explain:
> > >
> > > javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Untrusted
> Server
> > > Certificate Chain
> > > at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(DashoA6275)
> > > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> > > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> > > at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)
> > > at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)
> > > at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(DashoA6275)
> > > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> > > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA6275)
> > > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> > > at com.sun.net.ssl.internal.ssl.AppOutputStream.write(DashoA6275)
> > > at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:66)
> > > at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:124)
> > > at
> > >
> >
>
org.apache.commons.httpclient.methods.StringRequestEntity.writeRequest(StringRequestEntity.java:140)
> > > at
> > >
> >
>
org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:495)
> > > at
> org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:1973)
> > > at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:993)
> > > at
> > >
> org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:393)
> > > at
> > > org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:168)
> > > at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)
> > > at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:346)
> > >
> > > My custom SSLProtocol gets invoked this time but for some reason, the method
> > > defaultTrustManager.isServerTrusted(certificates) always returns false eventhough it is
> exactly
> > > the same which gets invoked in RC2 with the HostConfiguration.
> > > I can also see from my own logs that the same server certificates are sent to the HTTPClient
> but
> > > this time they are not recognized !
> > >
> > > By the way, even if Protocol.registerProtocol(), I cannot use it because it overrides all
> the
> > > SSL
> > > protocols at the level of the port. but in my custom client, I have different HTTPClients
> > > connecting to the same port but on different hosts.
> > >
> > > Any idea ?
> > >
> > > Thanks
> > > riad
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Tired of spam? Yahoo! Mail has the best spam protection around
> > > http://mail.yahoo.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> > >
> > >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Problem with V3 RC3 and
HTTPClient.getHostConfiguration().setHost("localhost", "443", sslProtocol)
not working anymore
Posted by Oleg Kalnichevski <ol...@apache.org>.
Riad,
Does your postmethod target a relative URL, and not an absolute one? If
it does not, make sure it does
sslProtocol = new Protocol("https", factory, "443");
HostConfiguration hostConf = new HostConfiguration();
hostConf.setHost("localhost", 443, sslProtocol)
// Will pick up sslProtocol from hostConf
PostMethod postmethod = new PostMethod("/relative");
client.executeMethod(hostConf, postmethod)
// Will ALWAYS pick up the default Protocol (the one registered using
// Protocol#registerProtocol
// hostConf will have no effect because the host and protocol are
// given in the URL itself
PostMethod postmethod = new PostMethod("https://localhost/absolute");
client.executeMethod(hostConf, postmethod);
Oleg
On Fri, 2005-07-22 at 11:33 -0700, Riad Souissi wrote:
> Hi again,
>
> I forgot to mention something:
>
> I am not using :
> - client.getHostConfiguration().setHost("localhost", 443, sslProtocol)
> I use instead:
> - hostConf.setHost("localhost", 443, sslProtocol)
> - client.executeMethod(hostConf, postmethod)
>
> But it is the same, it gives the same problem
>
> riad
>
>
> --- Riad Souissi <ri...@yahoo.com> wrote:
>
> > Hi,
> >
> > I had the following code which used to work from Beta1 to RC2 but stopped to work in RC3:
> >
> > HTTPClient client = ...
> > SecureProtocolSocketFactory factory = ...
> > sslProtocol = new Protocol("https", factory, "443");
> > client.getHostConfiguration().setHost("localhost", "443", sslProtocol);
> >
> > After I moved to RC3, I always have this java error:
> >
> > avax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: No trusted
> > certificate found
> > at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(DashoA6275)
> > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> > at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)
> > at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)
> > at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(DashoA6275)
> > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA6275)
> > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> > at com.sun.net.ssl.internal.ssl.AppOutputStream.write(DashoA6275)
> > at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:66)
> > at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:124)
> > at
> >
> org.apache.commons.httpclient.methods.StringRequestEntity.writeRequest(StringRequestEntity.java:140)
> > at
> >
> org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:495)
> > at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:1973)
> > at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:993)
> > at
> > org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:393)
> > at
> > org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:168)
> > at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)
> > at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:346)
> >
> > As if it does not use the custom SecureProtocolSocketFactory anymore (and from the traces in my
> > custom SecureProtocolSocketFactory, it never gets called)
> > Then for testing, I changed the last line of the code to: Protocol.registerProtocol("https",
> > sslProtocol)
> >
> > It still did not work, but for a different reason which I could not explain:
> >
> > javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Untrusted Server
> > Certificate Chain
> > at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(DashoA6275)
> > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> > at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)
> > at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)
> > at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(DashoA6275)
> > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA6275)
> > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> > at com.sun.net.ssl.internal.ssl.AppOutputStream.write(DashoA6275)
> > at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:66)
> > at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:124)
> > at
> >
> org.apache.commons.httpclient.methods.StringRequestEntity.writeRequest(StringRequestEntity.java:140)
> > at
> >
> org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:495)
> > at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:1973)
> > at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:993)
> > at
> > org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:393)
> > at
> > org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:168)
> > at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)
> > at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:346)
> >
> > My custom SSLProtocol gets invoked this time but for some reason, the method
> > defaultTrustManager.isServerTrusted(certificates) always returns false eventhough it is exactly
> > the same which gets invoked in RC2 with the HostConfiguration.
> > I can also see from my own logs that the same server certificates are sent to the HTTPClient but
> > this time they are not recognized !
> >
> > By the way, even if Protocol.registerProtocol(), I cannot use it because it overrides all the
> > SSL
> > protocols at the level of the port. but in my custom client, I have different HTTPClients
> > connecting to the same port but on different hosts.
> >
> > Any idea ?
> >
> > Thanks
> > riad
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> >
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Problem with V3 RC3 and HTTPClient.getHostConfiguration().setHost("localhost", "443", sslProtocol) not working anymore
Posted by Riad Souissi <ri...@yahoo.com>.
Hi again,
I forgot to mention something:
I am not using :
- client.getHostConfiguration().setHost("localhost", 443, sslProtocol)
I use instead:
- hostConf.setHost("localhost", 443, sslProtocol)
- client.executeMethod(hostConf, postmethod)
But it is the same, it gives the same problem
riad
--- Riad Souissi <ri...@yahoo.com> wrote:
> Hi,
>
> I had the following code which used to work from Beta1 to RC2 but stopped to work in RC3:
>
> HTTPClient client = ...
> SecureProtocolSocketFactory factory = ...
> sslProtocol = new Protocol("https", factory, "443");
> client.getHostConfiguration().setHost("localhost", "443", sslProtocol);
>
> After I moved to RC3, I always have this java error:
>
> avax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: No trusted
> certificate found
> at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(DashoA6275)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)
> at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)
> at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(DashoA6275)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA6275)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> at com.sun.net.ssl.internal.ssl.AppOutputStream.write(DashoA6275)
> at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:66)
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:124)
> at
>
org.apache.commons.httpclient.methods.StringRequestEntity.writeRequest(StringRequestEntity.java:140)
> at
>
org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:495)
> at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:1973)
> at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:993)
> at
> org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:393)
> at
> org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:168)
> at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)
> at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:346)
>
> As if it does not use the custom SecureProtocolSocketFactory anymore (and from the traces in my
> custom SecureProtocolSocketFactory, it never gets called)
> Then for testing, I changed the last line of the code to: Protocol.registerProtocol("https",
> sslProtocol)
>
> It still did not work, but for a different reason which I could not explain:
>
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Untrusted Server
> Certificate Chain
> at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(DashoA6275)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)
> at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)
> at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(DashoA6275)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA6275)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
> at com.sun.net.ssl.internal.ssl.AppOutputStream.write(DashoA6275)
> at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:66)
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:124)
> at
>
org.apache.commons.httpclient.methods.StringRequestEntity.writeRequest(StringRequestEntity.java:140)
> at
>
org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:495)
> at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:1973)
> at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:993)
> at
> org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:393)
> at
> org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:168)
> at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)
> at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:346)
>
> My custom SSLProtocol gets invoked this time but for some reason, the method
> defaultTrustManager.isServerTrusted(certificates) always returns false eventhough it is exactly
> the same which gets invoked in RC2 with the HostConfiguration.
> I can also see from my own logs that the same server certificates are sent to the HTTPClient but
> this time they are not recognized !
>
> By the way, even if Protocol.registerProtocol(), I cannot use it because it overrides all the
> SSL
> protocols at the level of the port. but in my custom client, I have different HTTPClients
> connecting to the same port but on different hosts.
>
> Any idea ?
>
> Thanks
> riad
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Problem with V3 RC3 and HTTPClient.getHostConfiguration().setHost("localhost", "443", sslProtocol) not working anymore
Posted by Riad Souissi <ri...@yahoo.com>.
Hi,
I had the following code which used to work from Beta1 to RC2 but stopped to work in RC3:
HTTPClient client = ...
SecureProtocolSocketFactory factory = ...
sslProtocol = new Protocol("https", factory, "443");
client.getHostConfiguration().setHost("localhost", "443", sslProtocol);
After I moved to RC3, I always have this java error:
avax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: No trusted
certificate found
at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.AppOutputStream.write(DashoA6275)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:66)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:124)
at
org.apache.commons.httpclient.methods.StringRequestEntity.writeRequest(StringRequestEntity.java:140)
at
org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:495)
at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:1973)
at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:993)
at
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:393)
at
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:168)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:346)
As if it does not use the custom SecureProtocolSocketFactory anymore (and from the traces in my
custom SecureProtocolSocketFactory, it never gets called)
Then for testing, I changed the last line of the code to: Protocol.registerProtocol("https",
sslProtocol)
It still did not work, but for a different reason which I could not explain:
javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Untrusted Server
Certificate Chain
at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.AppOutputStream.write(DashoA6275)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:66)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:124)
at
org.apache.commons.httpclient.methods.StringRequestEntity.writeRequest(StringRequestEntity.java:140)
at
org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:495)
at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:1973)
at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:993)
at
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:393)
at
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:168)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:346)
My custom SSLProtocol gets invoked this time but for some reason, the method
defaultTrustManager.isServerTrusted(certificates) always returns false eventhough it is exactly
the same which gets invoked in RC2 with the HostConfiguration.
I can also see from my own logs that the same server certificates are sent to the HTTPClient but
this time they are not recognized !
By the way, even if Protocol.registerProtocol(), I cannot use it because it overrides all the SSL
protocols at the level of the port. but in my custom client, I have different HTTPClients
connecting to the same port but on different hosts.
Any idea ?
Thanks
riad
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Problem with "Unbuffered entity enclosing request can not be repeated" when sending a large stream
Posted by Riad Souissi <ri...@yahoo.com>.
Thanks Oleg, I have not though about this option.
Will try it.
It would be nice through to have getContentStream() method in EntityEnclosingMethod to facilitate
custom classes which would derive from EntityEnclosingMethod class.
--- Oleg Kalnichevski <ol...@apache.org> wrote:
> Riad,
>
> A much, much better solution to this problem is to implement a custom
> RequestEntity class that can cleanly re-create the input stream:
>
>
http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/httpclient/methods/RequestEntity.html
>
> Oleg
>
>
> On Fri, Jul 22, 2005 at 07:21:19AM -0700, Riad Souissi wrote:
> > Hi
> >
> > - This issue appeared with version3 RC3 (I had no problem with RC1 and possibly RC2).
> > - I am sending a large file through HTTPClient. Since it is large, I avoid using buffering
> (stream
> > size is known, not equal to -1 or -2).
> > - When an error happen which involves the RetryHandler (derived from
> > DefaultHttpMethodRetryHandler), I used to reset the InputStream to position zero (either using
> > InputStream.mark(0) in the init phase then reset() or
> > ((FileInputStream)stream).getChannel().position(0) in JDK 1.4). This way, the retry mechanism
> will
> > reuse a properly initialized stream from its beginning.
> >
> > This used to work, however, with RC3, it seems from the source code that
> InputStreamRequestEntity
> > is not repeatable anymore (which I can understand in case a stream cannot be reset, but in
> many
> > case, may be most cases, it can be reset and reused).
> > This causes the "Unbuffered entity enclosing request can not be repeated" error and faisl the
> HTTP
> > call.
> >
> > This is the java stacktrace:
> >
> > org.apache.commons.httpclient.ProtocolException: Unbuffered entity enclosing request can not
> be
> > repeated.
> > at
> >
>
org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:483)
> > at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:1973)
> > at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:993)
> > at
> > org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:393)
> > at
> > org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:168)
> > at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)
> > at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:346)
> >
> > I wanted to rely fully on the RetryHandler of the HTTPClient rather than add another layer of
> > retrying on top of it, which I would like to avoid.
> > Do you guys have a nice solution ?
> > I would suggest that you make a method in InputStreamRequestEntity to force it to be
> repeatable if
> > the developer knows he can reuse and reset the stream. Is that possible ?
> >
> > Thanks
> > riad
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Problem with "Unbuffered entity enclosing request can not be repeated" when sending a large stream
Posted by Oleg Kalnichevski <ol...@apache.org>.
Riad,
A much, much better solution to this problem is to implement a custom
RequestEntity class that can cleanly re-create the input stream:
http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/httpclient/methods/RequestEntity.html
Oleg
On Fri, Jul 22, 2005 at 07:21:19AM -0700, Riad Souissi wrote:
> Hi
>
> - This issue appeared with version3 RC3 (I had no problem with RC1 and possibly RC2).
> - I am sending a large file through HTTPClient. Since it is large, I avoid using buffering (stream
> size is known, not equal to -1 or -2).
> - When an error happen which involves the RetryHandler (derived from
> DefaultHttpMethodRetryHandler), I used to reset the InputStream to position zero (either using
> InputStream.mark(0) in the init phase then reset() or
> ((FileInputStream)stream).getChannel().position(0) in JDK 1.4). This way, the retry mechanism will
> reuse a properly initialized stream from its beginning.
>
> This used to work, however, with RC3, it seems from the source code that InputStreamRequestEntity
> is not repeatable anymore (which I can understand in case a stream cannot be reset, but in many
> case, may be most cases, it can be reset and reused).
> This causes the "Unbuffered entity enclosing request can not be repeated" error and faisl the HTTP
> call.
>
> This is the java stacktrace:
>
> org.apache.commons.httpclient.ProtocolException: Unbuffered entity enclosing request can not be
> repeated.
> at
> org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:483)
> at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:1973)
> at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:993)
> at
> org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:393)
> at
> org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:168)
> at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)
> at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:346)
>
> I wanted to rely fully on the RetryHandler of the HTTPClient rather than add another layer of
> retrying on top of it, which I would like to avoid.
> Do you guys have a nice solution ?
> I would suggest that you make a method in InputStreamRequestEntity to force it to be repeatable if
> the developer knows he can reuse and reset the stream. Is that possible ?
>
> Thanks
> riad
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org