RE: HttpClient performance

[Kalnichevski, Oleg]

Zulfi,

If you expect us to react on this report, you have to be a little more specific on how 
exactly you measured the performance, exactly what kind of HTTP methods your tests 
included, exactly what pre-release-candidate you are referring to, and what exactly 
you mean by but it is still slower than using JDK-1.4.2. Do you actually mean using 
HttpURLConnection? Raw socket? Something else?

I'll run a few tests of my own to see if I get significant difference in terms of 
performance between HttpClient 2.0alpha3, 2.0.1, CVS HEAD (post-3.0a1) and 
HttpURLConnection

Oleg


-Original Message-
From: Zulfi Umrani [mailto:[EMAIL PROTECTED]
Sent: Friday, August 20, 2004 7:06 AM
To: [EMAIL PROTECTED]
Subject: HttpClient performance


Hi,

Just wanted to get the latest information on the performance issues
reported earlier. I have gone through the below emails from Archive, but
could not get a definite solution to the performance problem. Wondering
whether a definite solution was found and whether there is a patch
available. We tested the performance using pre-release-candidate version
of HttpClient(2.0) and it was much better than the release-candidate
versions and the final 2.0 version of HttpClient. Please note that I did
try using the  SimpleHttpConnectionManager and calling the
setConnectionStaleCheckingEnabled method with false argument. The
performance does improve, but it is still slower than using JDK-1.4.2. I
will appreciate if someone who knows the solution can respond.
   

http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=781750
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=781859
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=781909
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=779703

Thanks.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Performance HttpClient 2.0.1 vs HttpClient 2.0-alpha3 vs HttpURLConnection jre1.4

[Kalnichevski, Oleg]

.toExternalForm());
try {
httpclient.executeMethod(httpget);
httpget.getStatusCode();
consumeResponse(httpget.getResponseBodyAsStream());
} finally {
httpget.releaseConnection();
}
long end = System.currentTimeMillis();
total += (end - start);
}
System.out.println(Average GET time with HttpClient, payload ~12,000 byte: 
+ (total / N) +  ms);

total = 0;
for (int i = 0; i  N; i ++) {
long start = System.currentTimeMillis();
HttpURLConnection httpURLConnection = (HttpURLConnection) 
targeturl2.openConnection();
httpURLConnection.setUseCaches(false);
httpURLConnection.setAllowUserInteraction(false);
httpURLConnection.setDoInput(true);
httpURLConnection.setRequestMethod(GET);
httpURLConnection.connect();
httpURLConnection.getResponseCode();
consumeResponse(httpURLConnection.getInputStream());
long end = System.currentTimeMillis();
total += (end - start);
}
System.out.println(Average GET time with HttpURLConnection, payload ~12,000 
byte: 
+ (total / N) +  ms);

   File file = new File(stuff);
   
   N = 200;
   total = 0;
   for (int i = 0; i  N; i ++) {
long start = System.currentTimeMillis();
PostMethod httppost = new PostMethod(targeturl1.toExternalForm());
httppost.setRequestBody(new FileInputStream(file));
httppost.setRequestContentLength((int)file.length());
try {
httpclient.executeMethod(httppost);
httppost.getStatusCode();
consumeResponse(httppost.getResponseBodyAsStream());
} finally {
httppost.releaseConnection();
}
long end = System.currentTimeMillis();
total += (end - start);
   }
   System.out.println(Average POST time with HttpClient, payload ~300,000 byte: 
   + (total / N) +  ms);
   
   total = 0;
   for (int i = 0; i  N; i ++) {
long start = System.currentTimeMillis();
HttpURLConnection httpURLConnection = (HttpURLConnection) 
targeturl1.openConnection();
httpURLConnection.setUseCaches(false);
httpURLConnection.setAllowUserInteraction(false);
httpURLConnection.setDoInput(true);
httpURLConnection.setDoOutput(true);
httpURLConnection.setRequestMethod(POST);
postRequest(httpURLConnection.getOutputStream(), file);
httpURLConnection.connect();
httpURLConnection.getResponseCode();
consumeResponse(httpURLConnection.getInputStream());
long end = System.currentTimeMillis();
total += (end - start);
   
}
   System.out.println(Average POST time with HttpURLConnection, payload ~300,000 
byte: 
   + (total / N) +  ms);
}
   
private static byte[] consumeResponse(final InputStream instream) throws 
IOException {
   
ByteArrayOutputStream buffer = new ByteArrayOutputStream(1024);
int l = -1;
byte[] tmp = new byte[1024];
while ((l = instream.read(tmp)) = 0) {
buffer.write(tmp, 0, l);
}
return buffer.toByteArray();
}

private static void postRequest(final OutputStream outstream, final File file)
throws IOException {
   
FileInputStream instream = new FileInputStream(file); 
int l = -1;
byte[] tmp = new byte[1024];
while ((l = instream.read(tmp)) = 0) {
outstream.write(tmp, 0, l);
}
}
}





-Original Message-
From: Kalnichevski, Oleg
Sent: Friday, August 20, 2004 9:39 AM
To: Commons HttpClient Project
Subject: RE: HttpClient performance



Zulfi,

If you expect us to react on this report, you have to be a little more specific on how 
exactly you measured the performance, exactly what kind of HTTP methods your tests 
included, exactly what pre-release-candidate you are referring to, and what exactly 
you mean by but it is still slower than using JDK-1.4.2. Do you actually mean using 
HttpURLConnection? Raw socket? Something else?

I'll run a few tests of my own to see if I get significant difference in terms of 
performance between HttpClient 2.0alpha3, 2.0.1, CVS HEAD (post-3.0a1) and 
HttpURLConnection

Oleg


-Original Message-
From: Zulfi Umrani [mailto:[EMAIL PROTECTED]
Sent: Friday, August 20, 2004 7:06 AM
To: [EMAIL PROTECTED]
Subject: HttpClient performance


Hi,

Just wanted to get the latest information on the performance issues
reported earlier. I have gone through the below emails from Archive, but
could not get a definite solution to the performance problem. Wondering
whether a definite solution

RE: HttpClient ConnectionTimeOut

[Kalnichevski, Oleg]

Karthi

HttpClient what version are you using 2.0.x (stable) or 3.0-alpha1. HttpClient 2.0 
throws org.apache.commons.httpclient.HttpConnection.ConnectionTimeoutException to 
signal a connect timeout. HttpClient 3.0 does 
org.apache.commons.httpclient.ConnectTimeoutException

Oleg

-Original Message-
From: Karthikeyani K [mailto:[EMAIL PROTECTED]
Sent: Freitag, 20. August 2004 15:55
To: [EMAIL PROTECTED]
Subject: HttpClient ConnectionTimeOut


Hi,
  We have set ConnectionTimeout for httpclient to 1 milliseconds. What 
exeception does it throw when a Connection times out. How do we track that a 
connection has timed out. If a connection times out, we need to send a response to the 
user to try later.

Thanks,
Karthi



-
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!

***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: HttpClient ConnectionTimeOut

[Kalnichevski, Oleg]

Yes, it is.

-Original Message-
From: Karthikeyani K [mailto:[EMAIL PROTECTED]
Sent: Freitag, 20. August 2004 16:24
To: Commons HttpClient Project
Subject: RE: HttpClient ConnectionTimeOut


Oleg,
 Thanks. We are using HttpClient 2.0 version downloaded from 
http://jakarta.apache.org/site/binindex.cgi.  Is this the correct location to download 
the jar files.

Thanks,
Karthi

Kalnichevski, Oleg [EMAIL PROTECTED] wrote:

Karthi

HttpClient what version are you using 2.0.x (stable) or 3.0-alpha1. HttpClient 2.0 
throws org.apache.commons.httpclient.HttpConnection.ConnectionTimeoutException to 
signal a connect timeout. HttpClient 3.0 does 
org.apache.commons.httpclient.ConnectTimeoutException

Oleg

-Original Message-
From: Karthikeyani K [mailto:[EMAIL PROTECTED]
Sent: Freitag, 20. August 2004 15:55
To: [EMAIL PROTECTED]
Subject: HttpClient ConnectionTimeOut


Hi,
We have set ConnectionTimeout for httpclient to 1 milliseconds. What exeception 
does it throw when a Connection times out. How do we track that a connection has timed 
out. If a connection times out, we need to send a response to the user to try later.

Thanks,
Karthi



-
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!

***
The information in this email is confidential and may be legally privileged. Access to 
this email by anyone other than the intended addressee is unauthorized. If you are not 
the intended recipient of this message, any review, disclosure, copying, distribution, 
retention, or any action taken or omitted to be taken in reliance on it is prohibited 
and may be unlawful. If you are not the intended recipient, please reply to or forward 
a copy of this message to the sender and delete the message, any attachments, and any 
copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: PostMethod setQueryString

[Kalnichevski, Oleg]

Query params are part of the request URL and as such can be used with any HTTP method. 
A request body on the other hand can be sent by so called entity enclosing methods 
only (such as POST and PUT). PostMethod.setRequestBody(NameValuePair[]) method takes a 
array of name/value pairs and constructs a request body out of them using URL 
encoding. PostMethod.setQueryString(NameValuePair[]) method can be used to pass 
parameters as a part of the request URL

HTH

Oleg

-Original Message-
From: Karthikeyani K [mailto:[EMAIL PROTECTED]
Sent: Freitag, 20. August 2004 17:30
To: [EMAIL PROTECTED]
Subject: PostMethod setQueryString


Hi,
   What is the difference between invoking setQueryString(NameValuePair[]) and 
setRequestBody(NameValuePair[])  on PostMethod.

When we try to use setQueryString(NameValuePair[]), we are getting the response 
back.
But when we try to use setRequestBody(NameValuePair[]), we are getting the 
response 500.

Does PostMethod.setQueryString(NameValuePair[]) pass parameters in the 
requestbody? Is it similar to PostMethod.setReqeustBody(NameValuePair[]).

Thanks,
Karthi




-
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.

***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[PATCH] 'Response content length is not known' warning

[Kalnichevski, Oleg]

Folks,

Here's the patch to tone down warning messages generated by the readResponseBody 
method when encountering non-fatal protocol violations. All changes are mostly 
cosmetical, so I'll apply the patch tonight (~ 21:00GMT) if I hear no loud complaints 
by then

Oleg

PS: the patch is against 2.0 branch


Index: java/org/apache/commons/httpclient/HttpMethodBase.java
===
RCS file: 
/home/cvspublic/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpMethodBase.java,v
retrieving revision 1.159.2.30
diff -u -r1.159.2.30 HttpMethodBase.java
--- java/org/apache/commons/httpclient/HttpMethodBase.java  27 Jul 2004 01:34:48 
-  1.159.2.30
+++ java/org/apache/commons/httpclient/HttpMethodBase.java  19 Aug 2004 08:25:43 
-
@@ -2008,9 +2008,9 @@
 private InputStream readResponseBody(HttpConnection conn)
 throws IOException {

-LOG.trace(enter HttpMethodBase.readResponseBody(HttpState, HttpConnection));
+LOG.trace(enter HttpMethodBase.readResponseBody(HttpConnection));

-responseBody = null; // is this desired?
+responseBody = null;
 InputStream is = conn.getResponseInputStream();
 if (Wire.CONTENT_WIRE.enabled()) {
 is = new WireLogInputStream(is, Wire.CONTENT_WIRE);
@@ -2044,10 +2044,7 @@
 }
 }
 } else {
-if (LOG.isWarnEnabled()) {
-LOG.warn(Transfer-Encoding is set but does not contain 
\chunked\: 
-+ transferEncoding);
-}
+LOG.info(Response content is not chunk-encoded);
 // The connection must be terminated by closing
 // the socket as per RFC 2616, 3.6
 setConnectionCloseForced(true);
@@ -2062,8 +2059,8 @@
 if (connectionHeader != null) {
 connectionDirective = connectionHeader.getValue();
 }
-if (!close.equalsIgnoreCase(connectionDirective)) {
-LOG.warn(Response content length is not known);
+if (isHttp11()  !close.equalsIgnoreCase(connectionDirective)) 
{
+LOG.info(Response content length is not known);
 setConnectionCloseForced(true);
 }
 result = is;   



-Original Message-
From: Kalnichevski, Oleg
Sent: Wednesday, August 18, 2004 12:14 PM
To: Commons HttpClient Project
Subject: RE: Response content length is not known



 Otherwise, dynamically generated content would have been a major problem
 with HTTP/1.0, or so I figure.


Actually it has been as a problem. That is primarily why HTTP/1.1 had to introduce the 
generic 'transfer-encoding' mechanism and the chunk encoding as its default 
implementation. Anyways, you are right. HTTP/1.0 responses that include an entity body 
may ommit the 'content-lenght' header.

I'll provide a patch to disable the warning for HTTP/1.0 responses

Oleg



-Original Message-
From: Roland Weber [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 18, 2004 11:46 AM
To: Commons HttpClient Project
Subject: RE: Response content length is not known


Hi Oleg,

Kalnichevski, Oleg [EMAIL PROTECTED] wrote on

18.08.2004 11:26:10:

  HTTP/1.0 200 OK[\r][\n]
  Date: Thu, 19 Aug 2004 02:01:34 GMT[\r][\n]
  Server: Oracle9iAS (9.0.3.0.0) Containers for J2EE[\r][\n]
  Content-Type: text/html[\r][\n]


 As you can see the response does not contain a 'content-length'

 header which is mandatory for the 200 (OK) response, hence the warning

 RFC1945


 7.2 Entity Body


 ...


 For response messages, ... [a]ll 1xx (informational), 204 (no

 content), and 304 (not modified) responses must not include a body.

 All other responses must include an entity body or a Content-Length

 header field defined with a value of zero (0).




 /RFC1945

It says or. Meaning if there is a body, there is no need
for the Content-Length header, right? It's mandatory only
with value 0, to indicate that there is no body. Otherwise,
dynamically generated content would have been a major problem
with HTTP/1.0, or so I figure. But I'm not familiar with
RFC 1945, so please correct me if I'm wrong.

cheers,
  Roland

***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments

RE: Response content length is not known

[Kalnichevski, Oleg]

Joseph,

Here's the response sent by the server

 HTTP/1.0 200 OK[\r][\n]
 Date: Thu, 19 Aug 2004 02:01:34 GMT[\r][\n]
 Server: Oracle9iAS (9.0.3.0.0) Containers for J2EE[\r][\n]
 Content-Type: text/html[\r][\n]

As you can see the response does not contain a 'content-length' header which is 
mandatory for the 200 (OK) response, hence the warning

RFC1945

7.2 Entity Body

...

For response messages, ... [a]ll 1xx (informational), 204 (no content), and 304 (not 
modified) responses must not include a body. All other responses must include an 
entity body or a Content-Length header field defined with a value of zero (0).

/RFC1945

I hope this clarifies things a little. As a work-around you may want to set 
HttpClient's log verbosity to ERROR. For a real fix do consider reporting this problem 
to Oracle

Oleg


-Original Message-
From: joseph mercado [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 18, 2004 4:42 AM
To: Commons HttpClient Project
Subject: Re: Response content length is not known


Hi list;
   Thanks to michael i generated the wire log. Here it
is. This is the last page where i posted. I did'nt get
the reponsebody. Can anyone explain it.

2004-08-18 10:06:07,686 DEBUG
[org.apache.commons.httpclient.HttpMethodBase] Should
force-close connection.
2004-08-18 10:06:07,686 DEBUG
[org.apache.commons.httpclient.HttpConnection] enter
HttpConnection.close()
2004-08-18 10:06:07,686 DEBUG
[org.apache.commons.httpclient.HttpConnection] enter
HttpConnection.closeSockedAndStreams()
2004-08-18 10:06:07,686 DEBUG
[org.apache.commons.httpclient.HttpConnection] enter
HttpConnection.releaseConnection()
2004-08-18 10:06:07,686 DEBUG
[org.apache.commons.httpclient.MultiThreadedHttpConnectionManager]
enter
HttpConnectionManager.releaseConnection(HttpConnection)
2004-08-18 10:06:07,686 DEBUG
[org.apache.commons.httpclient.MultiThreadedHttpConnectionManager]
Freeing connection,
hostConfig=HostConfiguration[host=203.215.79.212,
protocol=http:80, port=80]
2004-08-18 10:06:07,686 DEBUG
[org.apache.commons.httpclient.MultiThreadedHttpConnectionManager]
enter
HttpConnectionManager.ConnectionPool.getHostPool(HostConfiguration)
2004-08-18 10:06:07,686 DEBUG
[org.apache.commons.httpclient.MultiThreadedHttpConnectionManager]
Notifying no-one, there are no waiting threads
2004-08-18 10:06:07,686 DEBUG
[org.apache.commons.httpclient.HttpMethodBase] enter
getContentCharSet( Header contentheader )
2004-08-18 10:06:07,686 DEBUG
[org.apache.commons.httpclient.HeaderElement] enter
HeaderElement.parse(String)
2004-08-18 10:06:07,686 DEBUG
[org.apache.commons.httpclient.HeaderElement] enter
HeaderElement.parsePair(char[], int, int)
2004-08-18 10:06:07,686 DEBUG
[org.apache.commons.httpclient.HeaderElement] enter
HeaderElement.parsePair(char[], int, int)
2004-08-18 10:06:07,696 DEBUG
[org.apache.commons.httpclient.methods.GetMethod]
enter GetMethod(String)
2004-08-18 10:06:07,696 DEBUG
[org.apache.commons.httpclient.methods.PostMethod]
enter PostMethod.addParameter(String, String)
2004-08-18 10:06:07,696 DEBUG
[org.apache.commons.httpclient.methods.EntityEnclosingMethod]
enter EntityEnclosingMethod.clearRequestBody()
2004-08-18 10:06:07,696 DEBUG
[org.apache.commons.httpclient.HttpClient] enter
HttpClient.executeMethod(HttpMethod)
2004-08-18 10:06:07,696 DEBUG
[org.apache.commons.httpclient.HttpClient] enter
HttpClient.executeMethod(HostConfiguration,HttpMethod,HttpState)
2004-08-18 10:06:07,696 DEBUG
[org.apache.commons.httpclient.MultiThreadedHttpConnectionManager]
enter
HttpConnectionManager.getConnection(HostConfiguration,
long)
2004-08-18 10:06:07,696 DEBUG
[org.apache.commons.httpclient.MultiThreadedHttpConnectionManager]
HttpConnectionManager.getConnection:  config =
HostConfiguration[host=203.215.79.212,
protocol=http:80, port=80], timeout = 0
2004-08-18 10:06:07,696 DEBUG
[org.apache.commons.httpclient.MultiThreadedHttpConnectionManager]
enter
HttpConnectionManager.ConnectionPool.getHostPool(HostConfiguration)
2004-08-18 10:06:07,696 DEBUG
[org.apache.commons.httpclient.MultiThreadedHttpConnectionManager]
enter
HttpConnectionManager.ConnectionPool.getHostPool(HostConfiguration)
2004-08-18 10:06:07,696 DEBUG
[org.apache.commons.httpclient.MultiThreadedHttpConnectionManager]
Getting free connection,
hostConfig=HostConfiguration[host=203.215.79.212,
protocol=http:80, port=80]
2004-08-18 10:06:07,696 DEBUG
[org.apache.commons.httpclient.HttpConnection] enter
HttpConnection.open()
2004-08-18 10:06:07,706 DEBUG
[org.apache.commons.httpclient.HttpConnection]
HttpConnection.setSoTimeout(0)
2004-08-18 10:06:07,706 DEBUG
[org.apache.commons.httpclient.HttpMethodBase] enter
HttpMethodBase.execute(HttpState, HttpConnection)
2004-08-18 10:06:07,706 DEBUG
[org.apache.commons.httpclient.HttpMethodBase] Execute
loop try 1
2004-08-18 10:06:07,706 DEBUG
[org.apache.commons.httpclient.HttpMethodBase] enter
HttpMethodBase.processRequest(HttpState,
HttpConnection)
2004-08-18 10:06:07,706 DEBUG

RE: Response content length is not known

[Kalnichevski, Oleg]

 Otherwise, dynamically generated content would have been a major problem
 with HTTP/1.0, or so I figure.

Actually it has been as a problem. That is primarily why HTTP/1.1 had to introduce the 
generic 'transfer-encoding' mechanism and the chunk encoding as its default 
implementation. Anyways, you are right. HTTP/1.0 responses that include an entity body 
may ommit the 'content-lenght' header.

I'll provide a patch to disable the warning for HTTP/1.0 responses

Oleg



-Original Message-
From: Roland Weber [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 18, 2004 11:46 AM
To: Commons HttpClient Project
Subject: RE: Response content length is not known


Hi Oleg,

Kalnichevski, Oleg [EMAIL PROTECTED] wrote on
18.08.2004 11:26:10:

  HTTP/1.0 200 OK[\r][\n]
  Date: Thu, 19 Aug 2004 02:01:34 GMT[\r][\n]
  Server: Oracle9iAS (9.0.3.0.0) Containers for J2EE[\r][\n]
  Content-Type: text/html[\r][\n]

 As you can see the response does not contain a 'content-length'
 header which is mandatory for the 200 (OK) response, hence the warning

 RFC1945

 7.2 Entity Body

 ...

 For response messages, ... [a]ll 1xx (informational), 204 (no
 content), and 304 (not modified) responses must not include a body.
 All other responses must include an entity body or a Content-Length
 header field defined with a value of zero (0).


 /RFC1945

It says or. Meaning if there is a body, there is no need
for the Content-Length header, right? It's mandatory only
with value 0, to indicate that there is no body. Otherwise,
dynamically generated content would have been a major problem
with HTTP/1.0, or so I figure. But I'm not familiar with
RFC 1945, so please correct me if I'm wrong.

cheers,
  Roland

***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Response content length is not known

[Kalnichevski, Oleg]

It does'nt show the html is not descriptive enough for me. I would still need to 
know if the method returns null, an empty string, or a string containing blanks only.

Besides, I am not convinced that the server sends anything back at all. Aside form a 
bogus warning I see nothing wrong in what HttpClient is doing.

The best thing you could do to help solve the problem is to capture the HTTP traffic 
between the browser and the web server using a traffic analyzer. Knowing exactly what 
kind of input the server expects, I'd be able to tell how to configure HttpClient to 
produce the exact or compatible HTTP requests.

Another thing you may try is turning off the HTTP/1.1 support by calling

post.setHttp11(false);

Hope this helps

Oleg

-Original Message-
From: joseph mercado [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 18, 2004 12:43 PM
To: Commons HttpClient Project
Subject: RE: Response content length is not known


it does'nt show the html

i just got

INFO:
http://203.215.79.212/reg-dir/submitApplication.do
WARN: Response content length is not known

--- Kalnichevski, Oleg
[EMAIL PROTECTED] wrote:


 What does post.getResponseBodyAsString() produce?

 Oleg

 -Original Message-
 From: joseph mercado [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, August 18, 2004 11:56 AM
 To: Commons HttpClient Project
 Subject: RE: Response content length is not known


 i fully understand what you had said. But my
 question
 is when i try to post data using a browser (ie) i
 got
 the last page shown on my browser? is there some
 thing
 i miss?

 below is the snipplet where i post :

 for(int x = 0; x  param.size(); x++){
   Vector form = (Vector) param.elementAt(x); //
 this holds nodeName and nodeValue
   //System.out.println(form.size());
   
   //lets post to the first url
   

URL=https://ereg.bir.gov.ph/ereg/+url[x].toString();
   

//URL=http://203.215.79.212/reg-dir/+url[x].toString();
   System.out.println(URL);
   post = new PostMethod(URL);
   
   // assemble the nvpair parameter to be posted
   for(int i=0;i  form.size(); i++){
   String[] array =
 form.elementAt(i).toString().split(,);
   post.addParameter(array[0],array[1]);
   }

   //once post data is assembled in a nvpair
 format
 lets post it
   client.executeMethod(post);
   
   //now lets get the HTTP status code and the
 responseBody
   if(post.getStatusCode() == HttpStatus.SC_OK){
 //HTTP 200
   //we only want to get the reposnsebody 
 of the
 last page
   if(x == 7 || x == 6){ //6 is confirm 
 page
 while
 7 is the message page
   
 System.out.println(post.getResponseBodyAsString());
   }
   //then we continue posting to the next 
 page
   continue;
   }else{
   //get the http status and close 
 connection
   System.out.println(Unexpected 
 failure: 
 +post.getStatusLine().toString());
   post.releaseConnection();
   
   //roll back msg to mq
   ctx.setRollbackOnly();
   break;
   }




 --- Kalnichevski, Oleg
 [EMAIL PROTECTED] wrote:

 
  Joseph,
 
  Here's the response sent by the server
 
   HTTP/1.0 200 OK[\r][\n]
   Date: Thu, 19 Aug 2004 02:01:34 GMT[\r][\n]
   Server: Oracle9iAS (9.0.3.0.0) Containers for
  J2EE[\r][\n]
   Content-Type: text/html[\r][\n]
 
  As you can see the response does not contain a
  'content-length' header which is mandatory for the
  200 (OK) response, hence the warning
 
  RFC1945
 
  7.2 Entity Body
 
  ...
 
  For response messages, ... [a]ll 1xx
  (informational), 204 (no content), and 304 (not
  modified) responses must not include a body. All
  other responses must include an entity body or a
  Content-Length header field defined with a value
 of
  zero (0).
 
  /RFC1945
 
  I hope this clarifies things a little. As a
  work-around you may want to set HttpClient's log
  verbosity to ERROR

RE: Unable to parse header: HTTP/1.0 200 OK

[Kalnichevski, Oleg]

Mathias

It appears to be a problem with the server side script. Some badly written CGI scripts 
generate HTTP status line + response headers in addition to those automatically 
generated by the web server. If you produced the wire log of the session that exhibits 
the problem, I'd be able to tell for sure. Please refer to the HttpClient logging 
guide for details

http://jakarta.apache.org/commons/httpclient/logging.html

Oleg

-Original Message-
From: Mathias Cianci [mailto:[EMAIL PROTECTED]
Sent: Friday, August 13, 2004 2:29 PM
To: Commons HttpClient Project
Subject: Unable to parse header: HTTP/1.0 200 OK


Yes, it's mathias again :o)

I get this error message :

INFO: Recoverable exception caught when processing request
13 ao¹t 2004 14:25:40 org.apache.commons.httpclient.HttpMethodBase
processRequest
ATTENTION: Recoverable exception caught but
MethodRetryHandler.retryMethod() returned false, rethrowing exception
A recoverable exception occurred,
retrying.org.apache.commons.httpclient.HttpException: Unable to parse
header: HTTP/1.0 200 OK
13 ao¹t 2004 14:25:40 org.apache.commons.httpclient.HttpMethodBase
processRequest

Where does it com from ?
The header seems to be corrrect ...

***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: timeout while waiting from reponse body ?

[Kalnichevski, Oleg]

Setting socket timeout to a positive value will do the trick

HttpClient client = new HttpClient();
client.setTimeout(6); // 60 sec timeout

-Original Message-
From: Mathias Cianci [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 12, 2004 2:50 PM
To: Commons HttpClient Project
Subject: timeout while waiting from reponse body ?


Hello everybody,

Sometimes, when this code line is executed :
byte[] responseBody = method.getResponseBody();
my thread is blocked because the response is not coming.

Is there a way to put something like a timeout in order to stop the
thread after 1minute if  the response is not coming ?

Hope an HttpClient-lover will give me an answer

Mathias

***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: timeout while waiting from reponse body ?

[Kalnichevski, Oleg]

You are more than welcome to ask any kind of HttpClient related questions

Oleg

-Original Message-
From: Mathias Cianci [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 12, 2004 3:02 PM
To: Commons HttpClient Project
Subject: Re: timeout while waiting from reponse body ?


Thank you Oleg and excuse me for asking such questions.
I was searching with the TimeoutController class, and I've not seen the
obvious answer.

Kalnichevski, Oleg a écrit :

Setting socket timeout to a positive value will do the trick

HttpClient client = new HttpClient();
client.setTimeout(6); // 60 sec timeout

-Original Message-
From: Mathias Cianci [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 12, 2004 2:50 PM
To: Commons HttpClient Project
Subject: timeout while waiting from reponse body ?


Hello everybody,

Sometimes, when this code line is executed :
byte[] responseBody = method.getResponseBody();
my thread is blocked because the response is not coming.

Is there a way to put something like a timeout in order to stop the

thread after 1minute if  the response is not coming ?

Hope an HttpClient-lover will give me an answer

Mathias

***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you 
are not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



 


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: timeout while waiting from reponse body ?

[Kalnichevski, Oleg]

Mathias,
It is a well known problem. In prehistorical times getResponseBody method has been 
made to silently discard I/O exceptions instead of propagating them back to the 
caller. We can't fix the problem without breaking the 2.0 API, so its resolution will 
have to wait until 3.0 release

We encourage HttpClient users to use getResponseBodyAsStream to process the response 
content for the time being

Oleg

-Original Message-
From: Mathias Cianci [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 12, 2004 3:33 PM
To: Commons HttpClient Project
Subject: Re: timeout while waiting from reponse body ?


Ok, so if I can ask stupid questions, I will not obstruct myself :o)

Here is a light version of my code :

HttpClient client = new HttpClient();
client.setTimeout(6);
  
HttpMethod method = null;
try {
method = new MyGetMethod(adresse);
} catch(Exception e) {
new Erreur(21;Erreur lors du décodage de l'URL
+e.getMessage(), Pas de code source, this);
}

// Execute the method.
int statusCode = -1;
// We will retry up to 3 times.
for (int attempt = 0; statusCode == -1  attempt  3; attempt++) {
try {
statusCode = client.executeMethod(method);
} catch (HttpRecoverableException e) {
System.err.println(A recoverable exception occurred,
retrying. + e.getMessage());
} catch (IOException e) {
System.err.println(Failed to download file.);
}
}

// Check that we didn't run out of retries.
if (statusCode == -1) {
System.err.println(Failed to recover from exception.);
}

// Read the response body.
try {
byte[] responseBody = method.getResponseBody();
leCode.set(new String(responseBody, this.getCodageUrl()));
} catch (SocketTimeoutException e) {
System.err.println(timeout error + e.getMessage());
} catch (Exception e) {
System.out.println(mauvais encodage);
}

// Release the connection.
method.releaseConnection();


The problem is that hte method.getReponseBody can't throw a
SocketTimeoutException but that's this method who is giving me problems



Kalnichevski, Oleg a écrit :

You are more than welcome to ask any kind of HttpClient related questions

Oleg

-Original Message-
From: Mathias Cianci [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 12, 2004 3:02 PM
To: Commons HttpClient Project
Subject: Re: timeout while waiting from reponse body ?


Thank you Oleg and excuse me for asking such questions.
I was searching with the TimeoutController class, and I've not seen the

obvious answer.

Kalnichevski, Oleg a écrit :

 

Setting socket timeout to a positive value will do the trick

HttpClient client = new HttpClient();
client.setTimeout(6); // 60 sec timeout
   


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: parameter of setHost method in HostConfiguration of httpClient

[Kalnichevski, Oleg]

Karthi,

HostConfiguration associated with HttpClient instance represents default host 
information. These settings are used only when the target host and port are not 
explicitly specified on the HttpMethod level.

HttpClient agent = new HttpClient();
agent.getHostConfiguration().setHost(localhost, 8080);

HttpMethod absolute = new GetMethod(www.whatever.com/stuff);
// will target the host specified in the URL

HttpMethod relative = new GetMethod(/stuff);
// no host name given in the URL. Will target the default host, that is 'localhost'

Hope this clarifies things a little

Oleg




-Original Message-
From: Karthikeyani K [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 10, 2004 15:39
To: [EMAIL PROTECTED]
Subject: parameter of setHost method in HostConfiguration of httpClient


Hi,
When we set Host on the HostConfiguration of the httpClient using setHost method 
(setHost(host)), does the host correspond to the server host or the client host.

When I try to close a connection by using
  cleint.getHttpConnectionmanager.getConnection(client.getHostConfiguration()).close,
I am getting the error stating host is null. So I have to set the host on the 
hostConfiguration, so does this host correspond to the server host or the client host 
itself.

Please advice.


Thanks,
Karthi


-
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!

***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: parameter of setHost method in HostConfiguration of httpClient

[Kalnichevski, Oleg]

Karthi,

Host configuration specified at the HTTP method level is not supposed to be propagated 
back to the HTTP client level.

Try this instead

  // Close the connection
   
client.getHttpConnectionManager().getConnection(method.getHostConfiguration()).close

Better yet, subclass the connection manager and make it always close connections upon 
release (if that is what you want). The way you are trying to get this done seems a 
little flaky to me. HttpConnectionManager#getConnection method will produce ANY 
connection for the given host config, not the one that has just been used to execute 
the request.

Cheers,

Oleg

-Original Message-
From: Karthikeyani K [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 10, 2004 16:57
To: Commons HttpClient Project
Subject: RE: parameter of setHost method in HostConfiguration of
httpClient


Thanks Kalnichevski. But I have specified the host at the method level :
for eg:
HttpClient client = new HttpClient();
PostMethod method =  new PostMethod(http://test:80/test.html);
//After executing the post method when i try to close the connection, i get 
the error message host is null
   method.releaseConnection();
  // Close the connection
   
client.getHttpConnectionManager().getConnection(client.getHostConfiguration()).close() 
  


There is a method setHost(URI uri) in HostConfiguration. So I was thinking this should 
be the URI same as that specified in the PostMethod.i.e that of the server


Thanks,
Karthi

Kalnichevski, Oleg [EMAIL PROTECTED] wrote:

Karthi,

HostConfiguration associated with HttpClient instance represents default host 
information. These settings are used only when the target host and port are not 
explicitly specified on the HttpMethod level.

HttpClient agent = new HttpClient();
agent.getHostConfiguration().setHost(localhost, 8080);

HttpMethod absolute = new GetMethod(www.whatever.com/stuff);
// will target the host specified in the URL

HttpMethod relative = new GetMethod(/stuff);
// no host name given in the URL. Will target the default host, that is 'localhost'

Hope this clarifies things a little

Oleg




-Original Message-
From: Karthikeyani K [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 10, 2004 15:39
To: [EMAIL PROTECTED]
Subject: parameter of setHost method in HostConfiguration of httpClient


Hi,
When we set Host on the HostConfiguration of the httpClient using setHost method 
(setHost(host)), does the host correspond to the server host or the client host.

When I try to close a connection by using
cleint.getHttpConnectionmanager.getConnection(client.getHostConfiguration()).close,
I am getting the error stating host is null. So I have to set the host on the 
hostConfiguration, so does this host correspond to the server host or the client host 
itself.

Please advice.


Thanks,
Karthi


-
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!

***
The information in this email is confidential and may be legally privileged. Access to 
this email by anyone other than the intended addressee is unauthorized. If you are not 
the intended recipient of this message, any review, disclosure, copying, distribution, 
retention, or any action taken or omitted to be taken in reliance on it is prohibited 
and may be unlawful. If you are not the intended recipient, please reply to or forward 
a copy of this message to the sender and delete the message, any attachments, and any 
copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
Do you Yahoo!?
Express yourself with Y! Messenger! Free. Download now.

***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: parameter of setHost method in HostConfiguration of httpClient

[Kalnichevski, Oleg]

The former (option 1) is the correct one. The latter (option 2) _should_ work with the 
simple connection manager but it is guaranteed to not produce the desired effect with 
the multi-threaded connection manager

Oleg

-Original Message-
From: Karthikeyani K [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 10, 2004 18:58
To: Commons HttpClient Project
Subject: RE: parameter of setHost method in HostConfiguration of
httpClient


Kalnichevski,
   I want to close the client connection once the method has been executed. Still 
I am not clear.Here is what I understand...There are two ways of doing it. Which 
option is the proper way of closing a client connection. Is my understanding correct.

1)public  class myHttpConnectionManager extends SimpleHttpConnectionManager
public myHttpConnectionManager() {};
public void releaseConnection(HttpConnection connection) {
   super.releaseConnection(connection);
   connection.close();
   }
   
}
   HttpClient client = new HttpClient( myHttpConnectionManager);
PostMethod method =  new PostMethod(http://test:80/test.html);
  //After executing the post method when i try to close the
connection, i get the error message host is null
   method.releaseConnection();
  // Close the connection
  client.getHttpConnectionManager().releaseConnection().


 or

   2)HttpClient client = new HttpClient( myHttpConnectionManager);
PostMethod method =  new PostMethod(http://test:80/test.html);
  //After executing the post method when i try to close the
connection, i get the error message host is null
   method.releaseConnection();
  // Close the connection
  
client.getHttpConnectionManager().getConnection(method.getHostConfiguration()).close().


  Does this close the connection that was used to execute the method.


Thanks,
Karthi


Kalnichevski, Oleg [EMAIL PROTECTED] wrote:

Karthi,

Host configuration specified at the HTTP method level is not supposed to be propagated 
back to the HTTP client level.

Try this instead

// Close the connection
client.getHttpConnectionManager().getConnection(method.getHostConfiguration()).close

Better yet, subclass the connection manager and make it always close connections upon 
release (if that is what you want). The way you are trying to get this done seems a 
little flaky to me. HttpConnectionManager#getConnection method will produce ANY 
connection for the given host config, not the one that has just been used to execute 
the request.

Cheers,

Oleg

-Original Message-
From: Karthikeyani K [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 10, 2004 16:57
To: Commons HttpClient Project
Subject: RE: parameter of setHost method in HostConfiguration of
httpClient


Thanks Kalnichevski. But I have specified the host at the method level :
for eg:
HttpClient client = new HttpClient();
PostMethod method = new PostMethod(http://test:80/test.html);
// After executing the post method when i try to close the connection, i get the error 
message host is null
method.releaseConnection();
// Close the connection
client.getHttpConnectionManager().getConnection(client.getHostConfiguration()).close()


There is a method setHost(URI uri) in HostConfiguration. So I was thinking this should 
be the URI same as that specified in the PostMethod.i.e that of the server


Thanks,
Karthi

Kalnichevski, Oleg wrote:

Karthi,

HostConfiguration associated with HttpClient instance represents default host 
information. These settings are used only when the target host and port are not 
explicitly specified on the HttpMethod level.

HttpClient agent = new HttpClient();
agent.getHostConfiguration().setHost(localhost, 8080);

HttpMethod absolute = new GetMethod(www.whatever.com/stuff);
// will target the host specified in the URL

HttpMethod relative = new GetMethod(/stuff);
// no host name given in the URL. Will target the default host, that is 'localhost'

Hope this clarifies things a little

Oleg




-Original Message-
From: Karthikeyani K [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 10, 2004 15:39
To: [EMAIL PROTECTED]
Subject: parameter of setHost method in HostConfiguration of httpClient


Hi,
When we set Host on the HostConfiguration of the httpClient using setHost method 
(setHost(host)), does the host correspond to the server host or the client host.

When I try to close a connection by using
cleint.getHttpConnectionmanager.getConnection(client.getHostConfiguration()).close,
I am getting the error stating host is null. So I have to set the host on the 
hostConfiguration, so does this host correspond to the server host or the client host 
itself.

Please advice.


Thanks,
Karthi


-
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!

***
The information in this email is confidential

RE: parameter of setHost method in HostConfiguration of httpClient

[Kalnichevski, Oleg]

 So using option 1, will close only the exact connection opened by the httpclient in
 helper class. i.e the connection that is used to invoke the post method on the
 httpclient.   It does not close any arbitrary connection. Am I right?

You are right.

Oleg

-Original Message-
From: Karthikeyani K [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 10, 2004 19:37
To: Commons HttpClient Project
Subject: RE: parameter of setHost method in HostConfiguration of
httpClient


Thanks a lot Kalnichevski for your detailed answers,

Just one more final clarification ..

our scenario is as follows

We have a Servlet which invokes an EJB and the EJB invokes a helper class which uses 
httpclient to post a request to an ASP page on a different server using NTLM 
authentication. After reading the response we want to close the connection openned by 
this httpclient used by the helper class.

So using option 1, will close only the exact connection opened by the httpclient in 
helper class. i.e the connection that is used to invoke the post method on the 
httpclient.   It does not close any arbitrary connection. Am I right?


Thanks,
Karthi



Kalnichevski, Oleg [EMAIL PROTECTED] wrote:

The former (option 1) is the correct one. The latter (option 2) _should_ work with the 
simple connection manager but it is guaranteed to not produce the desired effect with 
the multi-threaded connection manager

Oleg

-Original Message-
From: Karthikeyani K [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 10, 2004 18:58
To: Commons HttpClient Project
Subject: RE: parameter of setHost method in HostConfiguration of
httpClient


Kalnichevski,
I want to close the client connection once the method has been executed. Still I am 
not clear.Here is what I understand...There are two ways of doing it. Which option 
is the proper way of closing a client connection. Is my understanding correct.

1)public class myHttpConnectionManager extends SimpleHttpConnectionManager
public myHttpConnectionManager() {};
public void releaseConnection(HttpConnection connection) {
super.releaseConnection(connection);
connection.close();
}

}
HttpClient client = new HttpClient( myHttpConnectionManager);
PostMethod method = new PostMethod(http://test:80/test.html);
// After executing the post method when i try to close the
connection, i get the error message host is null
method.releaseConnection();
// Close the connection
client.getHttpConnectionManager().releaseConnection().


or

2) HttpClient client = new HttpClient( myHttpConnectionManager);
PostMethod method = new PostMethod(http://test:80/test.html);
// After executing the post method when i try to close the
connection, i get the error message host is null
method.releaseConnection();
// Close the connection
client.getHttpConnectionManager().getConnection(method.getHostConfiguration()).close().


Does this close the connection that was used to execute the method.


Thanks,
Karthi


Kalnichevski, Oleg wrote:

Karthi,

Host configuration specified at the HTTP method level is not supposed to be propagated 
back to the HTTP client level.

Try this instead

// Close the connection
client.getHttpConnectionManager().getConnection(method.getHostConfiguration()).close

Better yet, subclass the connection manager and make it always close connections upon 
release (if that is what you want). The way you are trying to get this done seems a 
little flaky to me. HttpConnectionManager#getConnection method will produce ANY 
connection for the given host config, not the one that has just been used to execute 
the request.

Cheers,

Oleg

-Original Message-
From: Karthikeyani K [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 10, 2004 16:57
To: Commons HttpClient Project
Subject: RE: parameter of setHost method in HostConfiguration of
httpClient


Thanks Kalnichevski. But I have specified the host at the method level :
for eg:
HttpClient client = new HttpClient();
PostMethod method = new PostMethod(http://test:80/test.html);
// After executing the post method when i try to close the connection, i get the error 
message host is null
method.releaseConnection();
// Close the connection
client.getHttpConnectionManager().getConnection(client.getHostConfiguration()).close()


There is a method setHost(URI uri) in HostConfiguration. So I was thinking this should 
be the URI same as that specified in the PostMethod.i.e that of the server


Thanks,
Karthi

Kalnichevski, Oleg wrote:

Karthi,

HostConfiguration associated with HttpClient instance represents default host 
information. These settings are used only when the target host and port are not 
explicitly specified on the HttpMethod level.

HttpClient agent = new HttpClient();
agent.getHostConfiguration().setHost(localhost, 8080);

HttpMethod absolute = new GetMethod(www.whatever.com/stuff);
// will target the host specified in the URL

HttpMethod relative = new GetMethod(/stuff);
// no host name given in the URL. Will target the default host

RE: how to accept all cookies ?

[Kalnichevski, Oleg]

Replace 

  System.setProperty(httpclient.cookiespec, COMPATIBILITY);

with

  HttpClient client = new HttpClient();
  client.getState().setCookiePolicy(CookiePolicy.COMPATIBILITY);

and see if that makes any difference.

Oleg

-Original Message-
From: Mathias Cianci [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 21, 2004 10:19
To: Commons HttpClient Project
Subject: Re: how to accept all cookies ?


Thank you for this answer, but I've already seen that :-(

Here's a part of my source code :

System.getProperties().setProperty(httpclient.useragent,
Mozilla/4.0 (compatible; MSIE 6.0; Windows XP));
System.setProperty(httpclient.cookiespec, COMPATIBILITY);

HttpClient client = new HttpClient();
  
HttpMethod method = new GetMethod(adresse);
method.setRequestHeader(Accept-Language,fr);
method.setRequestHeader(Accept-Charset, UTF-8);

Mathias

Kalnichevski, Oleg a écrit :

Mathias,

Try using the browser compatibility cookie policy. For details please refer to the 
HttpClient cookie guide:

http://jakarta.apache.org/commons/httpclient/cookies.html

Oleg



-Original Message-
From: Mathias Cianci [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 21, 2004 9:58
To: [EMAIL PROTECTED]
Subject: how to accept all cookies ?


Hello everybody,

When I'm sending requests to Yahoo search engine, I get this type of

warning message :

21 juil. 2004 09:56:32 org.apache.commons.httpclient.HttpMethodBase

processResponseHeaders
ATTENTION: Cookie rejected: $Version=0; B=deli0110fs8drb=2;

$Domain=.yahoo.com; $Path=/. Domain attribute .yahoo.com violates RFC

2109: host minus domain may not contain any dots


Does someone know how I can accept every cookie I receive, even if they

are not completly respect the official specifications ?

Thank you for advance

Mathias




***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you 
are not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



 



***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: how to accept all cookies ?

[Kalnichevski, Oleg]

Mathias,

I know it is of little comfort to you but the cookie clearly violates even the most 
loosely defines HTTP security policies. At least the site seems to send the invalid 
cookie to MSIE (or any agent identifying itself as MSIE) only

I see three possibilities to solve the problem

(1) I _assume_ that the host www.altavista.com may aslo have a DNS entry within the 
yahoo.com domain. See if can find it out and use it instead
(2) provide a custom cookie policy. Unfortunately pluggable cookie policies are 
supported by HttpClient 3.0 only, which is still in ALPHA
(3) Get HttpClient 2.0 source code and tweak it to your liking

Oleg


-Original Message-
From: Mathias Cianci [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 21, 2004 10:38
To: Commons HttpClient Project
Subject: Re: how to accept all cookies ?


Thank you Oleg, now it works !

But I still have another cookie problem :-(

Altavista have recently been acquired by Yahoo corp.
When you make requests in atltavista.com, you're now transparently
redirected to  yahoo.com (whitch puts a cookie for the domain
altavista.com), and then again to altavista.com.
As a result of this redirection, I get this warning message :

21 juil. 2004 10:26:52 org.apache.commons.httpclient.HttpMethodBase
processResponseHeaders
ATTENTION: Cookie rejected: B=f24p1390fsa6mb=2. Illegal domain
attribute .yahoo.com. Domain of origin: fr.altavista.com

How can I accept this cookie transparently ?

Mathias

Kalnichevski, Oleg a écrit :

Replace


  System.setProperty(httpclient.cookiespec, COMPATIBILITY);

with

  HttpClient client = new HttpClient();
  client.getState().setCookiePolicy(CookiePolicy.COMPATIBILITY);

and see if that makes any difference.

Oleg

-Original Message-
From: Mathias Cianci [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 21, 2004 10:19
To: Commons HttpClient Project
Subject: Re: how to accept all cookies ?


Thank you for this answer, but I've already seen that :-(

Here's a part of my source code :

System.getProperties().setProperty(httpclient.useragent,

Mozilla/4.0 (compatible; MSIE 6.0; Windows XP));
System.setProperty(httpclient.cookiespec, COMPATIBILITY);

HttpClient client = new HttpClient();
 

HttpMethod method = new GetMethod(adresse);
method.setRequestHeader(Accept-Language,fr);
method.setRequestHeader(Accept-Charset, UTF-8);

Mathias

Kalnichevski, Oleg a écrit :

 

Mathias,

Try using the browser compatibility cookie policy. For details please refer to the 
HttpClient cookie guide:

http://jakarta.apache.org/commons/httpclient/cookies.html

Oleg



-Original Message-
From: Mathias Cianci [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 21, 2004 9:58
To: [EMAIL PROTECTED]
Subject: how to accept all cookies ?


Hello everybody,

When I'm sending requests to Yahoo search engine, I get this type of

warning message :

21 juil. 2004 09:56:32 org.apache.commons.httpclient.HttpMethodBase

processResponseHeaders
ATTENTION: Cookie rejected: $Version=0; B=deli0110fs8drb=2;

$Domain=.yahoo.com; $Path=/. Domain attribute .yahoo.com violates RFC

2109: host minus domain may not contain any dots


Does someone know how I can accept every cookie I receive, even if they

are not completly respect the official specifications ?

Thank you for advance

Mathias




***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you 
are not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on 
it is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




   


 



***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you 
are not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system

RE: [VOTE] 2.0.1 release

[Kalnichevski, Oleg]

Folks,

I apologize for 'waking up' so late, after already having cast my vote.

(1) There are two patches that I would like to see committed before the release is cut

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=29897
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=30175

Both problems are relatively minor. If there are no loud objections I commit the 
patches around 20:00 GMT

(2) I would also like to propose Commons Pool based connection manager contributed by 
Andrea Fabris be included into the contrib package for the coming release. It is a 
fine contribution which may be valuable for some of our users

http://marc.theaimsgroup.com/?t=10838575947r=1w=2

The only trouble I see here is that an additional dependency on commons-pool. I 
personally feel this is acceptable as the contrib package is not meant to be an 
integral part of HttpClient and thus its dependencies should not be limited to those 
of HttpClient. I believe it is just matter of time until someone will come up with 
useful stuff that goes beyond the original scope of HttpClient which we may still want 
to ship with the official source distribution as reference material.

How do you feel about it?

Oleg


-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Monday, July 19, 2004 8:26
To: Commons HttpClient Project
Subject: Re: [VOTE] 2.0.1 release


+1

 
 --
   Vote:  HttpClient 2.0.1 release
   [x] +1 I am in favor of the release, and will help support it.
   [ ] +0 I am in favor of the release, but am unable to help support it.
   [ ] -0 I am not in favor of the release.
   [ ] -1 I am against this proposal (must include a reason).
   
 
 --


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Having some problems with expect 100 continue

[Kalnichevski, Oleg]

Jennifer,

(1) Are you using SSL?
(2) What's the JRE version you are using?
(3) What web server you are targeting?
(4) Are you going through a proxy?

Oleg

-Original Message-
From: Jennifer Ward [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 15, 2004 1:49
To: Commons HttpClient Project
Subject: Having some problems with expect 100 continue


All,

I'm now calling setUseExpectHeader(true) for my putMethod. However, I'm
running into a few problems.

First, when putting a 1 character text file (Content-Length: 3) it
doesn't authorize and eventually I get the 'Maximum redirects (100)
exceeded' exception.

If I take a slightly larger text file (Content-Length: 7), then all is
fine. However, I do get the INFO message:

Jul 14, 2004 4:40:33 PM org.apache.commons.httpclient.HttpMethodBase
processRequest
INFO: Recoverable exception caught when processing request

If I try to put a 1MB mpg file, the request appears to hang with:

Jul 14, 2004 4:41:44 PM org.apache.commons.httpclient.HttpMethodBase
writeRequest
INFO: 100 (continue) read timeout. Resume sending the request

Any suggestions? I did try this with the latest build of HttpClient
also and had similar results.

Thanks,
Jen



On Jul 14, 2004, at 11:43 AM, Oleg Kalnichevski wrote:

 On Wed, 2004-07-14 at 18:10, Jennifer Ward wrote:
 On Jul 13, 2004, at 8:03 PM, Michael Becke wrote:


 Another way to handle this problem is to use the expect 100
 continue
 feature of HTTP.  This feature is disabled in HttpClient by default,
 as only a few servers support it correctly.  You can re-enable it by
 calling setUseExpectHeader(true) on the post method.

 Yes, Oleg mentioned this a few days ago. It sounds like this feature
 still causes the request to get sent twice (even though the request
 body will not get sent if the server cannot receive it). I was hoping
 for a way to send each request only once (with the correct auth header
 the first time).

 Jennifer,

 This can be done if you are prepared to handle the entire
 authentication
 process manually (actually with HttpClient 3.0 it can be done quite
 easily). The question is if it is really worth the trouble. It is
 important to understand Digest authentication scheme is more secure
 primarily because it involves frequent challenge-response exchanges.
 The
 server generates a nonce which is used by the HTTP clients to produce
 the password digest. If the server is configured to change the nonce
 too
 often, that would basically defeat any sort of preemptive
 authentication
 mechanism, in the worst case rendering it even less efficient than
 'expect-continue' handshake. If the server is configured to keep the
 nonce for too long, that would inevitably make Digest authentication
 less secure. It is not impossible to strike a balance between
 efficiency
 and security. The question is whether the performance gains really
 justify additional complexity

 Oleg


 I'm not having much luck with that though, so I may
 end up using the expect 100 continue feature after all.

 Thanks
 Jen


 -
 To unsubscribe, e-mail:
 [EMAIL PROTECTED]
 For additional commands, e-mail:
 [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail:
 [EMAIL PROTECTED]
 For additional commands, e-mail:
 [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: SSL and server using self-signed certificate

[Kalnichevski, Oleg]

Andre

This is a very common problem. Please consult 'Customizing SSL' section of the 
HttpClient SSL guide for details on how the problem can be resolved

http://jakarta.apache.org/commons/httpclient/sslguide.html

Oleg


-Original Message-
From: Andre-John Mas [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 07, 2004 16:01
To: [EMAIL PROTECTED]
Subject: SSL and server using self-signed certificate


Hi,

I have set up a Tomcat 4.1 server to use SSL, with the help of a self-certified
certificate, ie with no trusted third party certifying it. I now try getting
my client, which uses 'commons-httpclient-2.0-rc2' to connect. When I do,
I get the following exception:

  sun.security.validator.ValidatorException: No trusted certificate found

Is there a way to get self-certified certifcates to be automatically trusted.
I must admit I am a newbie when it comes to SSL, so any help would be very much
appreciated.

regards

Andre


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

RE: multipart/form-data Boundary issues

[Kalnichevski, Oleg]

---BeginMessage---
Eric

There's a project currently hosted in the commons sandbox aimed at factoring multipart 
code out of HttpClient and eventually merging it with commons [codec]. 

http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/codec-multipart/

Feel free to take it as a starting point and consider contibuting your code back to 
the project

Oleg


-Original Message-
From:   Eric Dalquist [mailto:[EMAIL PROTECTED]
Sent:   Tue 6/29/2004 18:02
To: Commons HttpClient Project
Cc: 
Subject:Re: multipart/form-data Boundary issues


Ortwin Glck wrote:



 Eric Dalquist wrote:

 I've been looking through the code dealing with multipart form 
 uploads and have a few questions. First off, what happens if the text 
 that someone is uploading contains the boundary text since it is hard 
 coded in this implementation?


 Eric,
 Actually a hard coded boundary string is bad practice. It should be 
 randomly generated each time. Feel free to file a bug report.

 If your text is likely to contain the boundary string, you should use 
 some Content-Transfer-Encoding like Base64 or quoted-printable or 
 something. Please refer to the respective MIME specification 
 (RFC-2045, RFC-2046, RFC-2047 and RFC-2049).

 Also I'm actually looking at the code to reconstruct a 
 multipart/form-data message body from a set of files and named 
 parameters. I don't actually want to send a request, just create the 
 body and write it to a stream.


 That should pose no problem.

 My only issue is that I need to be able to set the boundary string 
 from my code.


 Why would one want to set the boundary string explicitly? A MIME 
 compliant server does not care about the actual boundary string value.


I have a special case for this one. I'm working no a bug fix for some 
portal software. The software currently reads the HttpRequest and parses 
out any submitted file data to temp files stored on the disk as they are 
being uploaded to cut down on memory requirements. The problem is at a 
later point in the request chain a wrapped instance of the same 
HttpRequest is passed to a JSR-168 portlet. To be standards compliant 
the portlet should just read the submitted file data from the input 
stream of the request but since the input stream has already been read 
and the files stored this is not possible, Our solution is to override 
the method that returns the ServletInputStream to the body of the 
request and re-construct the submitted body on the fly from the temp 
files and stored parameters. The boundary that was used by the 
submitting client is stored in the content type field and is easy to 
retrieve. Re-using this boundary would ensure that it is unique for the 
data since it was already used once and it would be one less method we 
have to override.

I actually decided to make our own implementation of the multipart 
creation classes. Looking through the httpclient code it would be a very 
large change since the code is based very largely around the use of 
static fields. This makes the code unusable in a multi-threaded environment.

If you would like I can post the final product of my code in a day or 
two when it is complete.

-Eric Dalquist

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




winmail.dat---End Message---
***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: HttpClient application

[Kalnichevski, Oleg]

Hi Pavel

Could you please confirm my understanding that actiWATE is free but not open-source? 
We tend to give a little more preferential treatment to open-source projects when it 
comes to placement on the HttpClient's application list

Oleg

-Original Message-
From: Pavel Sher [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 24, 2004 18:37
To: [EMAIL PROTECTED]
Subject: HttpClient application


Hello,

Is it possible to add a link to actiWATE product in the Applications
section on your site? actiWATE uses HttpClient for underlying HTTP
communications and is freeware.

The description might be as follows:

actiWATE is a Java-based software platform that is intended to
make web application testing simple and cost-effective.
actiWATE currently consists of:
- Advanced framework for writing test scripts in Java
- Test Writing Assistant - web browser plug-in module which is intended
to assist the test writing process


url: http://www.actiwate.com/


Thank you in advance.

--
Best regards,
 Pavel  mailto:[EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Logging Problem

[Kalnichevski, Oleg]

Tim,

* What is the exact JRE version that you are using?
* Are you running HttpClient in a container (servlet container, EJB container)?
* What other libraries do you have on the JRE's classpath?
* Have you tried setting those system properties upon the JRE startup using -D 
directive?

Oleg

-Original Message-
From: Tim Patton [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 24, 2004 19:06
To: [EMAIL PROTECTED]
Subject: Logging Problem


I've been trying to get logging output to debug a cookie problem but no luck
so far.  As far as I can tell from the docs, I just need these 4 lines of
code in my progrma somewhere:


System.setProperty(org.apache.commons.logging.simplelog.defaultlog,debug
);
  System.setProperty(org.apache.commons.logging.Log,
org.apache.commons.logging.impl.SimpleLog);
  System.setProperty(org.apache.commons.logging.simplelog.showdatetime,
true);

System.setProperty(org.apache.commons.logging.simplelog.log.httpclient.wire
, debug);

System.setProperty(org.apache.commons.logging.simplelog.log.org.apache.comm
ons.httpclient, debug);


Am I missing something else?  I get no logging output, but my program can
connect to a site and grab a page no problem.  I do not have Log4J anywhere
on my machine as far as I can tell.  I made a short test program to see what
was going on, I can send that to the list if it will help.

Tim


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Invalid RSA modulus size

[Kalnichevski, Oleg]

Tim,

I have had good results with IAIK JCE  SSL libraries. They are neither free nor 
open-source but seem just fine otherwise

http://jce.iaik.tugraz.at/products/index.php

You'd still need to check with the IAIK's technical folks if their JCE implementation 
is capable of handling larger keys

Hope this helps

Oleg



-Original Message-
From: Tim Wild [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 17, 2004 1:43
To: Commons HttpClient Project
Subject: Re: Invalid RSA modulus size


Thanks for that Oleg, you were indeed correct. Using JDK1.4 I couldn't
get this to work, but it worked pefectly on 1.5.0 beta 2. I had a few
problems getting all my certificates in the right place, but in the end
I got there. Eric, your -trustcacerts was helpful too, and thanks to
everyone who made suggestions.

We're using Sybase EAServer, and we're locked into using JDK 1.4.2_03.
Because of this I think i'll need to look into 3rd party JSSE or JCE
implementations. Bouncycastle is the only provider I know of, but they
don't seem to support TLS. Google isn't helping me much here. Does
anyone know of a suitable provider that might have a working version of
JSSE/JCE?

FYI the error i'm talking getting is:

javax.net.ssl.SSLProtocolException: java.io.IOException: subject key,
Unknown key spec: Invalid RSA modulus size.

One tip I found: if you generate your private key using openssl, then
get a certificate back from a CA, it can be hard to get this into your
Java keystore. The only way I know to do it is to create a pkcs12
certificate containing both your public and private key, the using
keytoolgui you have to use the import key pair option instead of using
import certificate. The java keytool can't do this because it doesn't
understand pcsk12, and there's no way I could find to import a private
key. The other option is to generate your private key using keytool, but
it's difficult to get the private key out of the keystore. Incidentally
keytoolgui has now been turned into a commercial product, but the old
one still works if you can find it.

I hope this helps someone, and I appreciate any suggestions anyone has
about my problem.

Tim

Oleg Kalnichevski wrote:

Tim,

This is believed to be a limitation of all Sun's JCE/JSSE
implementations up to Java version 1.5. You can try testing your
application with Java 1.5-b2 to see if the problem has indeed been
fixed. Alternatively consider using IBM Java 1.4 or 3rd party JCE/JSSE
implementations which _may_ not exhibit the same limitation

HTH

Oleg

On Sat, 2004-06-12 at 05:36, Tim Wild wrote:
 

Hi,

I'm using HttpClient to connect to an apache server that requires
certificates. When I use client and server certificates from my own CA
with 1024 bit keys it works perfectly. When I get a commercial
certificate with a longer key (4096 bits), I get the following error
(full message below) when I connect to apache:

javax.net.ssl.SSLProtocolException: java.io.IOException: subject key,
Unknown key spec: Invalid RSA modulus size.

Google produced one result, which talked about a maximum key size using
the JCE of 2048 bits using the JDK 1.4.2 default policy files. Another
site suggested getting the unrestricted policy files, so I got and
installed them, but it doesn't seem to make any difference at all.

Does anyone have any thought or suggestions? Half formed thoughs or
ideas are welcome as it might give me a lead that I can follow myself.

Thanks

Tim Wild

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

   



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Invalid RSA modulus size

[Kalnichevski, Oleg]

Tim,

You may want to completely override the default server certificate validation logic 
and provide your custom implementation.

Feel free to take AuthSSLProtocolSocketFactory.java and AuthSSLX509TrustManager.java 
classes below as a starting point

http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/ssl/?only_with_tag=HTTPCLIENT_2_0_BRANCH

Basically all it takes is to tweak AuthSSLX509TrustManager#isServerTrusted method and 
instead of delegating the control to the default trust manager implement the 
certificate chain validation that suits you best

 public boolean isServerTrusted(X509Certificate[] certificates) {
   ...
   return this.defaultTrustManager.isServerTrusted(certificates);
 }

HTH

Oleg

-Original Message-
From: Tim Wild [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 15, 2004 7:29
To: Commons HttpClient Project
Subject: Re: Invalid RSA modulus size


Thanks Michael. I have the CA cert and the chained CA certs in my
java_home/jre/lib/security/cacerts file. That CA issued the server
cert too. It all works fine when I use Mozilla.

I'm pretty sure it's a problem with certificate chaining, as when I use
my own test CA, which doesn't have an intermediate CA.

I use a custom socket factory that works perfectly with my own test CA
too, which I must get around to posting some time, once I work out the
IP issues.

Any more thoughts or suggestions?

Thanks

Tim

- Original Message -
From: Michael Becke [EMAIL PROTECTED]
Date: Tuesday, June 15, 2004 2:58 pm
Subject: Re: Invalid RSA modulus size

 Hi Tim,

 This generally means the the server's cert is signed by an
 untrusted
 CA.  You can get around this in a couple of ways.

  - import the servers cert into the keystore you are using
  - implement a SSL socket factory that is not so picky about who
 signed
 the cert.  This is not recommended for production use but can be
 useful
 for testing.  Take a look at the EasySSLProtocolSocketFactory
 described
 in 
 target=lhttp://jakarta.apache.org/commons/httpclient/sslguide.html
for an
 example.
  - Sign your server cert with a CA that is trusted by JSSE. 
 Please
 take a look at the JSSE docs for info about which CAs are trusted.

 Mike

 On Jun 14, 2004, at 10:19 PM, Tim Wild wrote:

  Thanks for that Oleg. Using JDK 1.5.0b2 does indeed get past the
  invalid modulus size error. I've got another error message
 now:
  javax.net.ssl.SSLHandshakeException:
  sun.security.validator.ValidatorException: No trusted
 certificate
  found.
 
  My apache server has a certificate from a certification
 authority
  called Digital Identity, in New Zealand. They have a root
 certificate
  authority, then two sub-CAs (perhaps called chained CAs). My
 server
  certificate and client certificate are chained under one of
 these
  sub-CAs. When I use Mozilla it all works perfectly, it requests
 the
  certificate, the browser presents it, and I can see the page I
  requested.
 
  When I try the same thing using Java I get the error message
 above. I
  have a keystore with just my client certiciate in it (nothing
 else),
  the same client certificate that works in Mozilla. I know it's
 finding
  the certificate because i'm having Java print out the alias of
 the
  certificate it's using. The CA certs are in the cacerts file of
 the
  JDK1.5 i'm using.
 
  Does anyone have any idea why i'm getting this error? Any
 thoughts or
  ideas about how to go forward or things to investigate would be
  welcome.
 
  Thanks
 
  Tim
 
  Oleg Kalnichevski wrote:
 
  Tim,
 
  This is believed to be a limitation of all Sun's JCE/JSSE
  implementations up to Java version 1.5. You can try testing your
  application with Java 1.5-b2 to see if the problem has indeed been
  fixed. Alternatively consider using IBM Java 1.4 or 3rd party
 JCE/JSSE implementations which _may_ not exhibit the same limitation
 
  HTH
 
  Oleg
 
  On Sat, 2004-06-12 at 05:36, Tim Wild wrote:
 
  Hi,
 
  I'm using HttpClient to connect to an apache server that
 requires
  certificates. When I use client and server certificates from
 my own
  CA with 1024 bit keys it works perfectly. When I get a
 commercial
  certificate with a longer key (4096 bits), I get the following
 error
  (full message below) when I connect to apache:
 
  javax.net.ssl.SSLProtocolException: java.io.IOException:
 subject
  key, Unknown key spec: Invalid RSA modulus size.
 
  Google produced one result, which talked about a maximum key
 size
  using the JCE of 2048 bits using the JDK 1.4.2 default policy
 files.
  Another site suggested getting the unrestricted policy files,
 so I
  got and installed them, but it doesn't seem to make any
 difference
  at all.
 
  Does anyone have any thought or suggestions? Half formed
 thoughs or
  ideas are welcome as it might give me a lead that I can follow
  myself.
 
  Thanks
 
  Tim Wild
 
  ---
 --
  To unsubscribe, 

RE: PostMethod 's recycle method has problem

[Kalnichevski, Oleg]

Himanshu,

Try setting socket timeout to a non-zero value. HttpMethod#recycle among many things 
calls HttpMethod#releaseConnection which in its turn attempts to reads the remaining 
response content to make sure that connection reusable. If the socket timeout is not 
set, releaseConnection may hang indefinitely under certain circumstances (target 
server is slow, congested network, etc)

Besides, I want to echo Odi's comment: there's nothing to be gained from method 
recycling. Just create a new HTTP method every time you need to execute an HTTP 
request. Do not forget to call HttpMethod#releaseConnection, though

Oleg

-Original Message-
From: Himanshu Thube [mailto:[EMAIL PROTECTED]
Sent: Friday, June 11, 2004 17:52
To: Commons HttpClient Project
Subject: Re: PostMethod 's recycle method has problem


Hi Christopher

Well thats the main problem. When my code comes to asynchPost.recycle()
in code below the program hangs !!

I am giving some code below to give an idea. This is not the original
code though. Does anybody know whats wrong here  ??


while(myflag) {

if(asyncState!=null) {
asynchPost.execute(asyncState,asyncConnection);
} else {
statusCode = asynchHttpsclient.executeMethod(asynchPost);
asyncState=asynchHttpsclient.getState();
}

if(asynchPost==null) {
if(usehttps) {
asynchPost = new PostMethod(httpsasynchUri.toString());
} else {
asynchPost = new PostMethod(httpasynchUri.toString());
}  
} else if (asynchPost.hasBeenUsed()) {
   asynchPost.recycle();
}
if(deviceProperty.getRequestObject()!=null) {
Document
request=(Document)deviceProperty.getRequestObject();   
asynchPost.setRequestBody(new
String(MyUtils.getBytesOfDom(request)));
}
}
Foran, Christopher wrote:

I think I know the answer to this one.  You need to call .recycle()
after every .execute().

-Original Message-
From: Himanshu Thube [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 10, 2004 10:18 PM
To: [EMAIL PROTECTED]
Subject: PostMethod 's recycle method has problem


Hi all,

Thanks for all your answers for my questions till now. I have a problem
with PostMethod. When I reuse the same method it gives a exception that
PostMethod  needs to be recycled. So I had put a check with help of
hasbeenUsed() method of PostMethod and trying to recycle the PostMethod.

Unfortunately my program hangs :( when it reaches recycle() call or even

if I try to print the ResponseBody of method.

Can someone let me know where could be the problem ??

Just to menthion, I am calling same post method with same request and
URL in a indefinite while loop until someone sets the while flag to
false.

- Himanshu


-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



 




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: HttpClient 2.0 problems

[Kalnichevski, Oleg]

Arturo,

unable to find line starting with 'HTTP' error is reported
(1) when response (status line, to be exact) sent by the server is malformed
(2) if HttpClient fails to correctly parse the status line sent by the server
(3) when the target server accepts connection but then fails to send any response back 
and simply drops the connection on unsuspecting HttpClient

The former two cases (1 and 2) are highly unlikely. They can easily be tested by 
examining the wire log produced by HttpClient. The former case (3) is by far more 
common and can occur when the target server is under heavy load. In this case the 
problem needs to be addressed on the server side and has nothing to do with HttpClient

Hope this helps

Oleg




-Original Message-
From: Arturo Esquivel Sanchez [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 10, 2004 12:20
To: [EMAIL PROTECTED]
Subject: HttpClient 2.0 problems





Hi,

The problem that im having is that sometimes i get the following error
when trying to connect to url, and then i change something in my code and
suddenly works fine, then i change something again and i get again the
same error (¿?), if a loop in my code in order to get a response other
than -1 it doesn´t work and i get a lots of the error.
This is the error:

[INFO] HttpMethodBase - -Recoverable exception caught when processing
request [WARN] HttpMethodBase - -Recoverable exception caught but
MethodRetryHandler.ret ryMethod() returned false, rethrowing exceptionA
recoverableexception occurred,  retrying.
org.apache.commons.httpclient.Http RecoverableException: Error in parsing
the status  line from the response: unabl e to find line starting with
HTTP
This is the code that im using:

  boolean retry=false;

  do{

statusCode = Procesa_Get_Url(url, client, config, state,
urlToConnect2, respHTML1);
if (statusCode != -1  urlToConnect2.toString().trim() !=  
urlToConnect2.toString().trim().length() != 0){
retry=true;}
  }while (retry==false);


 private int Procesa_Get_Url(String urlProc, HttpClient clientProc,
 HostConfiguration configProc, HttpState stateProc, StringBuffer urlTC,
 StringBuffer respHTML) throws Exception {int statusCode=-1;
String redirectLocation=null;

clientProc.setTimeout(60*30*1000);
clientProc.setHttpConnectionFactoryTimeout(60*30*1000);
clientProc.setConnectionTimeout(60*30*1000);

//try{

  //URI uri = new URI(urlProc.toCharArray());
  URI uri = new URI(urlProc.toCharArray());

  HttpMethod method = new GetMethod(uri.toString());

  String schema = uri.getScheme();

  if ((schema == null) || (schema.equals())){
schema = http;
  }

  Protocol protocol = Protocol.getProtocol(schema);

  String host = uri.getHost();
  int port = uri.getPort();

  configProc.setHost(host,port,protocol);
  
configProc.setProxy(System.getProperty(http.proxyHost),Integer.parseInt(System.getProperty(http.proxyPort,80)));
   stateProc.setProxyCredentials(null, null,
new UsernamePasswordCredentials(
  System.getProperty(http.proxyUserName),
  System.getProperty(http.proxyPassword)));

  int attempt=0;
  boolean retry=false;

  //do{
  //for (attempt = 0; statusCode == -1  attempt  3; attempt++) {
try{
  statusCode =
  clientProc.executeMethod(configProc,method,stateProc); //if
  (statusCode != -1){  //  retry=true;
  //}

} catch (HttpRecoverableException e) {
  method.recycle();
  method.releaseConnection();
  System.out.println(A recoverable exception occurred,
  retrying.   + e.getMessage());} catch
  (IOException e) {
  System.err.println(Failed to download file.);
  e.printStackTrace();
}catch (Exception e) {
  System.err.println(Errorsote.);
  e.printStackTrace();
}

  //}while (retry=false);

  if (statusCode == -1) {
System.err.println(Numero de Intentos: + attempt);
System.err.println(Failed to recover from exception.);
  }

  switch (statusCode){
case 200 :  stateProc.setCookiePolicy(CookiePolicy.RFC2109);
Cookie[] cookies =  stateProc.getCookies();
System.out.println(Present cookies: );
for (int i = 0; i  cookies.length; i++) {
  System.out.println( -  +
  cookies[i].toExternalForm());}
urlTC.append(method.getURI().toString());
respHTML.append(method.getResponseBodyAsString());
break;

case 302 :  stateProc.setCookiePolicy(CookiePolicy.RFC2109);
Cookie[] cookies2 =  stateProc.getCookies();

Deprecate HttpMethod#recycle

[Kalnichevski, Oleg]

Folks,
I suggest HttpMethod#recycle method be deprecated in 2.0 and 3.0. This has already 
been suggested by Eric a while ago. We should have listened

Oleg

***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: unable to find line starting with HTTP

[Kalnichevski, Oleg]

 - Maybe the problem is in our side and changing the URL (changing the
 server) implies destroying a broken object and creating a fresh one.
 The new object can handle the new connection without any problem.

 Could the second possibility be true in some aspect?

Juan,
I do not think this is very likely. Anyways, this can be easily tested by creating a 
new instance of HttpClient and hitting the same URL.

 Another question: what can I do to check whether the server is really
 working properly or not? Should I enable any kind of log?

You may consider running HttpClient with debug logging turned on and analyse the 
content of the resultant log file.

http://jakarta.apache.org/commons/httpclient/logging.html

 And finally: I'm thinking in starting to use
 MultiThreadedHttpConnectionManager. Is there anythig I should be worried
 about?

Have a look at the HttpClient threading guide

http://jakarta.apache.org/commons/httpclient/threading.html

 I've seen there is an open bug related to staleConnectionChecking.

I am not aware of any open bug related to stale connection check. Actually most (if 
not all) open bug reports are feature requests. See for yourself:

http://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemail1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Commonscomponent=HttpClientshort_desc=short_desc_type=allwordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doitnewqueryname=order=Reuse+same+sort+as+last+time

Hope this helps somewhat

Oleg


-Original Message-
From: Juan Pedro López Sáez [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 10, 2004 16:28
To: Commons HttpClient Project
Subject: Re: unable to find line starting with HTTP


Hello.

I return with my problem, now with more information.

Guys at the server side (the use Apache) told me they don't have any
problem related to dropping connections, and even they assure me the
server did receive my request and at least logged the response.

They have two servers: the main one and the failover server. In case the
first is in troubles we can try with the second.

If we get the unable to find the line starting with HTTP Exception and
keep trying with the same server, the exception is continously catched.
If we change to the failover one, the problem disappears.

I have two ideas about that:

- The main server is under heavy load or another similar problem, so it
drops our connections and the problem is solved when we try with the
other server.

- Maybe the problem is in our side and changing the URL (changing the
server) implies destroying a broken object and creating a fresh one.
The new object can handle the new connection without any problem.

Could the second possibility be true in some aspect?

In my code every HTTP POST request is handled by a new thread. I create
a HttpClient object in the beginning and manage the request inside a
loop, where I create a new PostMethod at every new iteration. If the
request doesn't success, PostMethod.releaseConnection() isn't called and
a new PostMethod (with the failover server's URL) is created to retry
the same POST. Anyway, the thread finally dies.

Another question: what can I do to check whether the server is really
working properly or not? Should I enable any kind of log?

And finally: I'm thinking in starting to use
MultiThreadedHttpConnectionManager. Is there anythig I should be worried
about? I've seen there is an open bug related to
staleConnectionChecking.

Thank you very much.

Juan Pedro López


 Thank you for your responses.

 Actually, I can't do anything in the server side because it's managed by
 an external service provider. I don't know what server are they running
 but I'll try to find it.

 I thought the problem was in the client side, but now I think I'll try
 to ask them to solve the problem. Retrying the requests could be a
 problem if the server really receives and processes them. 

 I'll tell you about this issue when I know new matters.

   Juan Pedro López

  I am seeing this exact same problem with 2.0rc1 as well.  A wget to the
  server from the same client works fine.  The httpclient wire log shows
  that I get a redirect and then the in waiting for the HTTP status line
  from the redirect, it never comes...
 
  What server are you running?
 
 -Eric
 
 
  Kalnichevski, Oleg wrote:
 
   Juan,
   Usually HttpClient reports 'unable to find line starting with HTTP' when the 
   target server drops the connection without returning any response. This can 
   happen, for instance, if the server is being under heavy load.
  
   (1) If you have access to the target server, examine the server logs to see why 
   the connection was dropped. Fixing the problem on the server side would

RE: Interruption connections

[Kalnichevski, Oleg]

Oliver,

Unfortunately there's no (standard and easy) way to interrupt execution of an HTTP 
method in HttpClient 2.0. This limitation has been fixed in the unstable branch 
(HttpClient 3.0). For the stable branch (HttpClient 2.0) there's no way around forking 
the stock version of HttpClient or (if your application does not use multithreaded 
connection manager) implementing your own connection manager

Sorry

Oleg

-Original Message-
From: Oliver Koell [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 08, 2004 18:34
To: Commons HttpClient Project
Subject: Interruption connections


Hi all,

i'm building a Swing app using HttpClient and, naturally, my users want
to be able to cancel slow HTTP requests (as in a Browser).

What would be the best way to accomplish this? Should i just interrupt
the HttpClient thread, or are there other (safer) methods to do this?

Thanks in advance

Oliver


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Interruption connections

[Kalnichevski, Oleg]

Hi Oliver

HttpMethod#abort should be what you want

Cheers,

Oleg


-Original Message-
From: Oliver Koell [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 08, 2004 19:07
To: Commons HttpClient Project
Subject: Re: Interruption connections


Hi Oleg,

thanks for your reply, and all the good work, too..

I'm actually already with the unstable branch. What is the preferred
way to cancel method execution in HttpClient 3.0?

Is this in any way related to which HttpConnectionManager i'm using?
(i'm using the SimpleHttpConnectionManager because i can assure that
there is only one HttpMethod executed at a time, although in different
SwingWorker threads).

Regards, Oliver


 Oliver,

 Unfortunately there's no (standard and easy) way to interrupt
 execution of an HTTP method in HttpClient 2.0. This limitation has
 been fixed in the unstable branch (HttpClient 3.0). For the stable
 branch (HttpClient 2.0) there's no way around forking the stock
 version of HttpClient or (if your application does not use
 multithreaded connection manager) implementing your own connection
 manager

 Sorry

 Oleg

 -Original Message-
 From: Oliver Koell [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, June 08, 2004 18:34
 To: Commons HttpClient Project
 Subject: Interruption connections


 Hi all,

 i'm building a Swing app using HttpClient and, naturally, my users want
 to be able to cancel slow HTTP requests (as in a Browser).

 What would be the best way to accomplish this? Should i just interrupt
 the HttpClient thread, or are there other (safer) methods to do this?

 Thanks in advance

 Oliver


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Retrieving server side certificate durring handshake?

[Kalnichevski, Oleg]

Marc,

HttpClient does not directly deal with any aspects of transport security. One is 
expected to provide a custom protocol socket factory in order to enforce the desired 
transport security.

See HttpClient SSL guide for details

http://jakarta.apache.org/commons/httpclient/sslguide.html

There is a new ssl socket factory pending inclusion into HttpClient 'contrib' package. 
This may be what you want

http://issues.apache.org/bugzilla/show_bug.cgi?id=29306

Oleg

-Original Message-
From: Marc Boorshtein [mailto:[EMAIL PROTECTED]
Sent: Monday, June 07, 2004 14:44
To: [EMAIL PROTECTED]
Subject: Retrieving server side certificate durring handshake?


Hello,

I have the http libraries working with SSL, but I need to be able to  
retrieve the server's certificate on connection.  I looked at the easy  
ssl protocol handler, but I didn't see anything that let me do this.   
Am I missing something, or is this handled at the JSSE level?

Thanks

 
--
Marc Boorshtein
Sr. Software Engineer, Octet String
[EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Problems with HttpClient

[Kalnichevski, Oleg]

Paulo,
Apparently you were looking at the HttpClient 3.0 code. The problem has indeed been 
already fixed in CVS HEAD. Make sure you select HTTPCLIENT_2_0_BRANCH tag when 
accessing CVS repository in order to retrieve the latest HttpClient 2.0 compatible code

http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/?only_with_tag=HTTPCLIENT_2_0_BRANCH

Oleg


-Original Message-
From:   Paulo Gaspar [mailto:paulo.gaspar]
Sent:   Tue 5/11/2004 17:13
To: Commons HttpClient Project
Cc: 
Subject:Re: Problems with HttpClient
  ...
  Do not use HttpMethodBase#getResponseBody or
  HttpMethodBase#getResponseBodyAsString methods. They are plain broken.
  Both methods are made to ignore I/O errors and return null instead of
  propagating IOException-s to the caller.
  ...

When did that happen?

That is not what I see on the sources I have, in which
HttpMethodBase.java has a 2004-03-25 20:37:20 timestamp.

In this version there is no big difference between using any of those
methods.

 From what I see, getResponseBodyAsString() uses the byte array built
by getResponseBody() to build a String from it. Building the String
from the array involves no I/O.

 public String getResponseBodyAsString() throws IOException {
 byte[] rawdata = null;
 if (responseAvailable()) {
 rawdata = getResponseBody();
 }
 if (rawdata != null) {
return EncodingUtil.getString(rawdata, getResponseCharSet());
 } else {
 return null;
 }
 }

Looking at how the byte array is built, I see that it uses
getResponseBodyAsStream() - which you say is OK - and reads it to that
stored-and-returned byte array without chocking any IOExceptions!

 public byte[] getResponseBody() throws IOException {
 if (this.responseBody == null) {
 InputStream instream = getResponseBodyAsStream();
 if (instream != null) {
 LOG.debug(Buffering response body);
 ByteArrayOutputStream outstream =
 new ByteArrayOutputStream();
 byte[] buffer = new byte[4096];
 int len;
 while ((len = instream.read(buffer))  0) {
 outstream.write(buffer, 0, len);
 }
 outstream.close();
 setResponseStream(null);
 this.responseBody = outstream.toByteArray();
 }
 }
 return this.responseBody;
 }

Is it bad in CVS now? Was it recently fixed?

I have no CVS access at the moment but, anyway, I think it is important
to make clear if something went wrong and must be fixed or if there is
a misunderstanding of some kind frome one of us about how this methods
are implemented.


Thanks, and have fun,
Paulo Gaspar


Oleg Kalnichevski wrote:
 Anoop,
 
 My guess is that some of the methods simply timeout while reading the
 response from the server. Unfortunately, HttpClient does not handle this
 situation well. Do not use HttpMethodBase#getResponseBody or
 HttpMethodBase#getResponseBodyAsString methods. They are plain broken.
 Both methods are made to ignore I/O errors and return null instead of
 propagating IOException-s to the caller. Whoever designed those methods
 did HttpClient a bad service. Use getResponseBodyAsStream and do the
 reading from the input stream as you see fit
 
 Cheers,
 
 Oleg
 
 
 On Fri, 2004-05-07 at 17:01, Anoop Adya wrote:
 
Hi
We have developed a client solution with the help of HttpClient.
During the trial run we noticed that it works smoothly for clients and
server within the same domain. However, if i try to use HttpClient over
multiple domains, I get a NullPointerException as getResponseBody returns
null.
Do we need to do something special to handle cross domain requests?
Note however that the user is in the same domain as the server we try to
access.

Any pointers would be greatly appreciated.

regards, Anoop.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Problem with https over proxy

[Kalnichevski, Oleg]

Dave,
I believe you may be much better off implementing a custom connection manager and 
still letting HttpClient take care of HTTP authentication, HTTPS tunneling and other 
stuff. 

Anyways, the sample below demonstrates how HTTPS tunneling can be implemented using 
just plain HttpConnection

http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/examples/Attic/CustomHttpConnection.java?rev=1.3.2.1only_with_tag=HTTPCLIENT_2_0_BRANCHview=markup

Oleg

-Original Message-
From:   Dave Seidel [mailto:[EMAIL PROTECTED]
Sent:   Fri 6/4/2004 15:07
To: 'Commons HttpClient Project'; [EMAIL PROTECTED]
Cc: 
Subject:RE: Problem with https over proxy
Thanks, Oleg.  I will look into doing it that way, but I'm not sure if that
technique will be flexible enough for us.  My application is atypical and
somewhat specialized, because we're using HttpClient to invoke SOAP
requests, and need a lot of low-level control.  We handle proxies and
authentication, and we need to log everything (headers and bodies), which
has made it necessary to subclass both GetMethod and PostMethod.  Looks like
I may have to subclass ConnectMethod as well.  (We also use HttpClient to
subclass HttpURLConnection.)

- Dave

-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 03, 2004 5:54 PM
To: Commons HttpClient Project
Subject: Re: Problem with https over proxy

Dave,
You are not using HttpConnection class to establish connection with the
target server, are you? 

Does you code look something like this?

HttpConnection conn = new HttpConnection(...);
conn.open();
HttpState httpstate = new HttpState();
GetMethod httpget = new GetMethod(https://www.whatever.com/;);
httpget.execute(conn, httpstate);

If it does, that would pretty much explain the problem, as the
connection management as well as proxy access are handled by HttpClient
class

If you want HTTPS tunneling to be taken care of automatically, you
should be using HttpClient class

HttpClient client = new HttpClient();
client.getHostConfiguration().setProxy(...);
GetMethod httpget = new GetMethod(https://www.whatever.com/;);
try {
  client.executeMethod(httpget);
} finally {
  httpget.releaseConnection();
}

I may still be wrong in my assumption, but that is the only thing I can
think of that can explain this kind of problem. 

Oleg


On Thu, 2004-06-03 at 23:07, Dave Seidel wrote:
 We embed HttpClient in our product (SOAPscope), and some of our users have
 reported a problem accessing https URLs if they use a proxy server.  I
tried
 this, and can readily recreate the problem (I'm using Squid).  I used
 TcpTrace to capture one of these requests, and compared it to the same
 request peformed by FireFox.  The FireFox request gets becomes a CONNECT
 before it gets sent to the proxy, and it works fine.  But the equivalent
 request from HttpClient just goes through as a GET and fails (since Squid
 won't handle a GET over https.
  
 What's the best way for me to fix this?  Should HttpClient handle the
 conversion from GET or POST to CONNECT, or do I have to handle it myself
in
 my client code (i.e., use ConnectMethod instead of PostMethod or
GetMethod,
 based on isSecure()  isProxied())?
  
 - Dave Seidel, Mindreef, Inc.


-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: unable to find line starting with HTTP

[Kalnichevski, Oleg]

Juan,
Usually HttpClient reports 'unable to find line starting with HTTP' when the target 
server drops the connection without returning any response. This can happen, for 
instance, if the server is being under heavy load. 

(1) If you have access to the target server, examine the server logs to see why the 
connection was dropped. Fixing the problem on the server side would be the best

(2) Another possible solution to this problem _may_ be to retry the request, provided 
that the POST methods your code is supposed to execute are idempotent. If the server 
application, however, has been designed in a way that it may receive a request, parse 
it, change the application state (by committing some data to the data store, for 
instance) and then simply drop the connection without giving any kind of response back 
to the client, you are in strongBIG/strong trouble, as simply retrying the same 
POST method case cause data inconsistency problems. So, the best thing to do is to get 
in touch with the server guys and find out if it is safe to retry POST methods.

Hope this clarifies things a little

Oleg



-Original Message-
From: Juan Pedro López Sáez [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 02, 2004 17:18
To: [EMAIL PROTECTED]
Subject: unable to find line starting with HTTP


Hi,

I've been searching in the archive list looking for something related to
my unable to find line starting with HTTP. 

There are lots of comments about it, but they all seem to be unuseful
for me.

Currently I'm using 2.0-rc3 version. My HTTP client is very simple.
Below you can see everything I do. That code is executed everytime I
need to send new data to the HTTP server.

--

HttpClient client= new HttpClient();
client.setStrictMode(true);
client.setTimeout(12); 
client.setConnectionTimeout(1); 

PostMethod post = new PostMethod(currentURL);
post.setRequestContentLength(XMLRequest.length());
post.setRequestBody(XMLRequest);
post.setRequestHeader(Content-type, text/xml; charset=ISO-8859-1);
post.addRequestHeader(Connection, close);

String response;

try{
httpStatus = client.executeMethod(post);
response = post.getResponseBodyAsString();
}
catch (HttpException e) {
log.fatal(IOException in client.executeMethod( post ),e);
throw e;
}
catch(IOException e){ 
log.fatal(IOException in client.executeMethod( post ),e);
throw e;
}
finally {
post.releaseConnection();
}



I'm getting the exception in the HttpClient.excetuteMethod line. The
exception happens from time to time, is not quite common but I don't
know what to do with it.  

The exception stack trace is the following:

org.apache.commons.httpclient.HttpRecoverableException:
org.apache.commons.httpclient.HttpRecoverableException: Error in parsing
the status  line from the response: unable to find line starting with
HTTP
at
org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1965)
at
org.apache.commons.httpclient.HttpMethodBase.processRequest(HttpMethodBase.java:2659)
at
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1093)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:674)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:529)

I would apreciate any help.

Thank you very much

Juan Pedro López




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: HttpClient problems

[Kalnichevski, Oleg]

Paul,

The problem is obviously caused by the server's dropping connection right after 
HttpClient is done sending the request. If you have access to the target server, check 
the server logs to find out what prompted the server to do so.

I can think of two possibilities:

(1) The server did not accept the request due to an authentication error (wrong 
credentials and stuff), immediately sent back 'unauthorized' response and dropped the 
connection while HttpClient was still busy sending the request body. 

If unsuccessful authentication is indeed the cause of the problem you can solve it by 
activating the '100-continue' handshake. See EntityEnclosingMethod javadocs for details

(2) The server dropped the connection due to a very high load or any other reason 
preventing it from successfully processing the request. Server log file is your best 
friend in this case

Hope this helps

Oleg

-Original Message-
From:   paul [mailto:[EMAIL PROTECTED]
Sent:   Thu 5/27/2004 14:25
To: Commons HttpClient Project
Cc: 
Subject:Re: HttpClient problems
Here's the wire log :
==
2004/05/26 20:09:50:262 SGT [DEBUG] MultiThreadedHttpConnectionManager - 
-HttpConnectionManager.getConnection:  config = HostConfiguration[hos
t=somewhere.com, protocol=https:443, port=443], timeout = 0
2004/05/26 20:09:50:262 SGT [DEBUG] MultiThreadedHttpConnectionManager - 
-Getting free connection, 
hostConfig=HostConfiguration[host=somewhere.com, protocol=https:443, 
port=443]
2004/05/26 20:09:50:263 SGT [DEBUG] HttpConnection - 
-HttpConnection.setSoTimeout(0)
2004/05/26 20:09:50:270 SGT [DEBUG] HttpMethodBase - -Execute loop try 1
2004/05/26 20:09:50:280 SGT [DEBUG] wire - - POST 
/fxlweb/XMLGateway.asp HTTP/1.1[\r][\n]
2004/05/26 20:09:50:281 SGT [DEBUG] HttpMethodBase - -Adding Host 
request header
2004/05/26 20:09:50:282 SGT [DEBUG] wire - - Content-type: text/xml; 
charset=ISO-8859-1[\r][\n]
2004/05/26 20:09:50:283 SGT [DEBUG] wire - - Authorization: Basic 
someencrypteddata[\r][\n]
2004/05/26 20:09:50:283 SGT [DEBUG] wire - - HTTP-Version: 
HTTP/1.1[\r][\n]
2004/05/26 20:09:50:284 SGT [DEBUG] wire - - Connection: 
Keep-Alive[\r][\n]
2004/05/26 20:09:50:285 SGT [DEBUG] wire - - User-Agent: Jakarta 
Commons-HttpClient/2.0final[\r][\n]
2004/05/26 20:09:50:286 SGT [DEBUG] wire - - Host: somewhere.com[\r][\n]
2004/05/26 20:09:50:287 SGT [DEBUG] wire - - Cookie: $Version=0; 
ASPSESSIONIDAACRQATR=DKBJEFCAIKAHLGIMJKIBEGBH; $Path=/[\r][\n]
2004/05/26 20:09:50:287 SGT [DEBUG] wire - - Content-Length: 594[\r][\n]
2004/05/26 20:09:50:288 SGT [DEBUG] wire - - [\r][\n]
2004/05/26 20:09:50:289 SGT [DEBUG] EntityEnclosingMethod - -Using 
unbuffered request body
2004/05/26 20:09:50:290 SGT [DEBUG] wire - - ?xml version=1.0 
encoding=UTF-8?xmldata here
2004/05/26 20:09:50:290 SGT [DEBUG] EntityEnclosingMethod - -Request 
body sent
2004/05/26 20:09:50:562 SGT [DEBUG] HttpMethodBase - -Closing the 
connection.
2004/05/26 20:09:50:563 SGT [INFO] HttpMethodBase - -Recoverable 
exception caught when processing request
2004/05/26 20:09:50:563 SGT [WARN] HttpMethodBase - -Recoverable 
exception caught but MethodRetryHandler.retryMethod() returned false, 
rethrow
ing exception
2004/05/26 20:09:50:564 SGT [DEBUG] MultiThreadedHttpConnectionManager - 
-Freeing connection, hostConfig=HostConfiguration[host=somewhere.com, 
protocol=https:443, port=443]
2004/05/26 20:09:50:564 SGT [DEBUG] MultiThreadedHttpConnectionManager - 
-Notifying no-one, there are no waiting threads
org.apache.commons.httpclient.HttpRecoverableException: 
java.net.SocketException: Connection reset
at 
org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1965)
at 
org.apache.commons.httpclient.HttpMethodBase.processRequest(HttpMethodBase.java:2659)
at 
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1093)
at 
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:675)
at 
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:529)
   

=
Thanks a lot for the info.

Ortwin Glck wrote:



 paul wrote:

 2004/05/26 20:09:50:564 SGT [DEBUG] 
 MultiThreadedHttpConnectionManager - -Notifying no-one, there are no 
 waiting threads
 org.apache.commons.httpclient.HttpRecoverableException: 
 java.net.SocketException: Connection reset
  at 
 org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1965) 

  at 
 org.apache.commons.httpclient.HttpMethodBase.processRequest(HttpMethodBase.java:2659)
  




 Does anybody know what causes the SocketException ? 


 Not yet, but we're gonna find out for you :-)

 Please produce a wirelog and send the section with the request / 
 response immediately preceding the exception.
 For instructions about how to make a wirelog please see our Logging 
 Guide:
 

RE: ConnectionTimeoutException thrown without waiting.

[Kalnichevski, Oleg]

Nicholas,

HttpClient 2.0 relies on a fairly ugly trick to be able to simulate connect timeout on 
older JDKs (1.2.x, 1.3.x). HttpClient simply spawns a dedicated thread that attempts 
to instantiate a socket. If the process of socket instantiation takes longer than the 
specified limit, HttpClient simply drops the socket on the floor and lets the garbage 
collection to clean up the mess. By no means this mechanism was intended to be 
reliable and sometimes may lead to all sorts of unpleasant side effects (for instance, 
rendering HttpClient EJB unfriendly). Would it be possible to disable the connect 
timeout and see if that makes any difference? I just wonder if the third call would 
still fail, if you had connect timeout disabled

Mike,
Any idea why closed connection is considered stale? 

snip
protected boolean isStale() {
boolean isStale = true;
if (isOpen) {
// the connection is open, but now we have to see if we can read it
// assume the connection is not stale.
isStale = false;
/snip

This does not really affect any functional aspects but unfortunately it results lots 
of scary noise in the debug log

Oleg


-Original Message-
From:   Nicholas Rahn [mailto:[EMAIL PROTECTED]
Sent:   Thu 5/27/2004 15:19
To: [EMAIL PROTECTED]
Cc: 
Subject:ConnectionTimeoutException thrown without waiting.
Hello,

We are using HttpClient 2.0 within a local network to send XML files
between 2 servers.  We send 4 XML documents in 4 separate requests, one
after the other.  The problem we are seeing is that the 3rd request does
not get sent due to a ConnectionTimeoutException.  We have set the
connection timeout to 5000 milliseconds, but in the logs we see that the
exception is thrown 2 milliseconds later.  After the 3rd request fails,
the 4th request works fine.

With each request we send the connection:close header so a new
connection should be opend every time.  One strange thing we see is that
after the 2nd request it takes about 20 seconds for HttpMethodBase to
acknowledge that the connection should be closed.  With the other
requests, this is almost instantanious.

I am not convinced this is an HttpClient problem as i am unable to
replicate the problem in my test environment (of course it only happens
in the production environment :-).  Maybe someone has some insight into
what's happening.

Here are our details:
HttpClient2-20040526
j2sdk1.4.2

I've included the wire and debug logs (with the XML documents removed). 
The INFO lines are from our application to give more detail on what the
exception was.

Thanks for your help,
Nick





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: GZip encoding

[Kalnichevski, Oleg]

Hi Mark,

It's been a conscious design decision on our part to keep HttpClient content agnostic. 
HttpClient makes no attempt to encode/decode (let alone guess) the request/response 
content encoding. This logic can be (and usually is) highly application specific that 
should be implemented on top of the standard HttpClient functionality. This said, we 
happily accept content specific classes to HttpClient contrib package.

Oleg


-Original Message-
From: Mark R. Diggory [mailto:[EMAIL PROTECTED]
Sent: Friday, May 21, 2004 17:42
To: Commons HttpClient Project
Subject: GZip encoding


We're having issues where content from our service is being sent GZip 
encoded to the HttpClient, But with an error that its gzip transfer 
encoding header isn't set properly by the server (thank our server 
developer). Most browsers (and clients in perl etc) seem to catch this 
error early and fall into GZip decoding. I would like to catch this 
condition and have the client still gzip decode the stream. First, does 
HttpClient support gzip decoding, and Second, is there a way I can force 
to gzip decode if the header is broken?

thanks,
Mark


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Question about cookies and Netscape-Enterprise/6.0 server

[Kalnichevski, Oleg]

Chris,

In the 'strict' mode HttpClient 2.0 will send all cookies as one request header. I 
believe that should take care of the problem. Some older HTTP servers appear to have 
issues with multiple Netscape-style (version 0) 'cookie' request headers.

HttpClient 3.0 provides a granular option to control the representation of cookies.

HTH

Oleg 

-Original Message-
From: Chris Lamprecht [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 19, 2004 8:50
To: Commons HttpClient Project
Subject: Question about cookies and Netscape-Enterprise/6.0 server


I'm using HttpClient 2.0-final to do a form-based login to a
Netscape-Enterprise 6.0 server (according to the HTTP headers).  It uses
cookies to maintain the session.

When I run HttpClient in RFC2109 cookie mode, it works fine.  However, when
I switch it to either compatibility or NETSCAPE_DRAFT mode, the server seems
to ignore the cookies that HttpClient sends it.  (The server acts like the
client isn't logged in).

I used Mozilla's LiveHTTPHeaders plugin to see what Mozilla sends when I log
in using Mozilla , and the Cookie: header line is as follows:

Cookie: NSC_vuejsfdu_443=c0a8061300bb;
FC=AQEBBwID6QIQRUYzQjVGQjIxxEYzNEY0OQMJY2wxMCAgICAgBAoxMDg0OTQ5Mzk0BQ02Ni4yN
S4xMzUuMTg0BgQwU1RBCgFZCxhDaHJpc3RvcGhlciBNIExhbXByZWNodCAIgK91mi9dn0bezpWdS
OT6xTLQtpKhlyRPYs+k2+fO0fTNBQmoYD3bgefyNTlxIxRxk9p86yrOPn27LNkhUeliJlg/X+oa5
/KZ0HAWOMUIK9OvJ6yFab7WZBR1Tll6TM85yriPLSBMpNSDsV03jEkHw/h7MqRztV9EVjsU92zJG
cj/; TS=20040519011947;
SC=AQEBBwID6QIQRUYzQjVGQjIxxEYzNEY0OQYkMUU0RUE1NzA2QzQ2M0E2NkY2MUY3RDg4MDA5M
jk5MUU5MzVBBAoxMDg0OTQ5Mzk0BQ02Ni4yNS4xMzUuMTg0CgFZCIC9uBG2A5H+exOVvOEm72d9X
4oikfjht7oIFztnGUU8xmXwnFCa7XQvy/cazgK1LTePofwUKhKD//izihmmqv6RlNpdbowSa0h8D
XZtqNFKtbUj8PP5Jk9y7ZKiiRKWXYx20tlQUlo5Iig0Ts9qizm6q8PamYursfYK9lielyXPYQ==;
PDLK=NONE; DOC=/registrar/reg/Pregistration.WBX

(That should all be on a single line).

The only difference I can see in HttpClient's wire log is that it puts one
cookie per line, and it doesn't end each cookie with a semicolon:

 GET /registrar/reg/Pregistration.WBX HTTP/1.1[\r][\n]
 Accept: image/gif, image/x-xbitmap, image/jpeg, */*[\r][\n]
 Accept-Language: en-us[\r][\n]
 Accept-Encoding: gzip, deflate[\r][\n]
 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR
1.0.3705)[\r][\n]
 Host: x.y.edu[\r][\n]
 Cookie: DOC=/index.html[\r][\n]
 Cookie: PDLK=NONE[\r][\n]
 Cookie:
SC=AQEBBwID6QIQRUYzQjVGQjIxNEYzNEY0OQYkOEM2RTI3RUM3MjQ4RDk4NTE5MDg5N0Y5QzhBQ
UVBODRCNjBDBAoxMDg0OTUwNTIzBQ02Ni4yNS4xMzUuMTg0CgFZCICgWfx0cCCdeTwbxBYeff42i
fXV/WWc26YqHzXnfl4CDNQazbhF3obVB6ve7SXMawMqHHfsPgcIpEbr5K5UjEcQyHO365s2OWnez
4ZiKiTtCS/dmHp+s8i5EIU/BiBJfUMmRxZ31Ll38js0OpUo5P518rZoN8g9waJCjfY2nm/kNg==[
\r][\n]
 Cookie: TS=20040519013842[\r][\n]
 Cookie:
FC=AQEBBwID6QIQRUYzQjVGQjIxNEYzNEY0OQMJY2wxMCAgICAgBAoxMDg0OTUwNTIzBQ02Ni4yN
S4xMzUuMTg0BgQwU1RBCgFZCxhDaHJpc3RvcGhlciBNIExhbXByZWNodCAIgLex5Xy9IKo6MG5SN
qeXcvQkqkm2SWeN50sDjvhWSAQPf1DKYpJaHaF2QF7NhQ8XyXVyDJmXzFz17wTPUUu6d/eqfoWmT
+J1N9gqycS7SjT8mb+7FPMoCxbt6iMiux0Gx40Gkepxbu+w3MhK+6FM549oWVGqgTSrHqL8+xgbT
3x3[\r][\n]
 Cookie: NSC_vuejsfdu_443=c0a8061301bb[\r][\n]

(Note:  I am intentionally setting the headers to appear like a normal
browser; that's why it says MSIE for User-Agent)

Any ideas why the server only recognizes RFC2109?

This isn't necessarily a big problem for me, since RFC2109 works, but I'm
trying to emulate a browser as _exactly_ as possible.  Thanks for your help.

Chris


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Supplying Credentials only when needed.

[Kalnichevski, Oleg]

Brian,

This feature is available in HttpClient 3.0 only:

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10794

Please note, though, that HttpClient 3.0 is still in an early alpha state

Oleg

-Original Message-
From: Russell, Brian [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 18, 2004 12:29
To: [EMAIL PROTECTED]
Subject: Supplying Credentials only when needed.


I am using http client 2.0

I have managed to use the NTCredentials to successfully authenticate
with an NTLM proxy, by providing the credentials to the HttpState

 Credentials proxyCred = new
NTCredentials(loggedInUserName,userPassword,,domainName);
 client.getState().setProxyCredentials(null,proxyCred);

This is all very well where I know for sure that there is an NTLM proxy
in place, and I can prompt the user for their Windows logon details, and
provide an instance of a Credentials object which is an NTCredentials.
My application, however, needs to cater for various environments, where
there may be no proxies, proxies authenticating by IP address, proxies
using Basic authentication etc etc.
Is it possible for httpclient to inform its caller when it encounters a
challenge, and to indicate what type of challenge it is. The caller can
then decide which type of Credentials object to supply to the state?

I don't know if what I am asking for exists, or if it is a new feature.
Hopefully the former.

Any comments would be appreciated.


Thanks,


Brian.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Posting XML over authenticated connection using SSL

[Kalnichevski, Oleg]

Lee Francis,

Now it hit me. 

When credentials are explicitly set to be used with a given host and/or realm only, 
there'll never be used for preemptive authentication for security reasons. The 
credentials will be used to respond to a direct authorization challenge originating 
from the specified host/realm.

client.getState().setCredentials(realm, host, upc);

You have got to provide default credentials in order for HttpClient to be able to send 
credentials preemptively

client.getState().setCredentials(null, null, upc);

This should do the trick

Oleg

-Original Message-
From: Lee Francis Wilhelmsen [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 18, 2004 15:03
To: Commons HttpClient Project
Subject: RE: Posting XML over authenticated connection using SSL


 Since you appear to be passing a custom HttpState object to the 
 HttpClient#executeMethod these lines of code have no effect of what so ever on the 
 method's execution

 client.getState().setAuthenticationPreemptive(true);
 client.getState().setCredentials(realm, host, upc);
 
 Try this instead

 httpState.setAuthenticationPreemptive(true);
 httpState.setCredentials(realm, host, upc);
 status = client.executeMethod(hostConfiguration, method, httpState);

 HTH

 Oleg

Sorry, it seems I 've made a mistake when showing you my example code in
  my prevous mail. I'm calling
client.executeMethod(method);
and not
client.executeMethod(hostConfiguration, method, httpState);
in my code.

Don't understand why the Authorization header isn't being sent in the
first request as expected when setting setAuthenticationPreemptive(true)

Any ideas?

Regards
Lee Francis

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: 3.0 alpha1 build [PATCH] status news

[Kalnichevski, Oleg]

Mike,

I feel we need a little stronger and more focused sales pitch. This is going to be a 
very important release for all of us and our message must be loud and clear with 
regards to what this release is intended to be and what its intended target is. If we 
fail to generate enough interest in the coming two to three months, we increase the 
risk of finding ourselves in an unpleasant situation with too many people expressing 
unhappiness with the new API after the official API freeze.

Here's my attempt at extending status  news pages. Feel free to make any 
modifications you deem necessary.

Oleg


-Original Message-
From: Michael Becke [mailto:[EMAIL PROTECTED]
Sent: Monday, May 17, 2004 6:11
To: Commons HttpClient Project
Subject: 3.0 alpha1 build


I've uploaded the 3.0 alpha1 build to my apache account
http://www.apache.org/~mbecke/httpclient-3.0-alpha1/.  Please have a
look and let me know if I've missed anything.  This release was created
with JDK1.3.1 since it seems that Maven RC2 does not work with 1.2.2. 
I don't think this will cause any issues, but if anyone is using 1.2.2
please give it a shot.  This is also the first time I've signed a
release.  My public key is in the KEYS file so please try that out as
well.

My plan is to finish this off tomorrow night and post the release.  I
was thinking of leaving the 2.0 docs as the main HttpClient page, and
just adding a link to the 3.0 version in another directory.

Mike


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: 3.0 alpha1 build [PATCH] status news

[Kalnichevski, Oleg]

Grrr.

This time inline
---

Index: news.xml
===
RCS file: /home/cvspublic/jakarta-commons/httpclient/xdocs/news.xml,v
retrieving revision 1.26
diff -u -r1.26 news.xml
--- news.xml17 May 2004 03:46:44 -  1.26
+++ news.xml17 May 2004 11:33:41 -
@@ -12,9 +12,39 @@
   body

 section name=17 May 2004 - HttpClient 3.0 alpha1 released
-  pWe are pleased to announce the first HttpClient 3.0 release.  This release 
contains quite a
-  number of additions and enhancements.  Please a 
href=downloads.htmldownload/a and
-  let us know what you think./p
+ pWe are pleased to announce the first HttpClient 3.0 release.
+  HttpClient 3.0 provides a wealth of features and enhancements
+  that did not make it into the 2.0 release while preserving API
+  compatibility as much as possible. In a relatively few case
+  a href=API_CHANGES_3_0.txtAPI compatibility with HttpClient
+  2.0/a could not maintained.
+ /p
+ p   
+  Most noteworthy enhancements include:
+  ul
+   liNew preference architecture/li
+   liImproved exception handling framework/li
+   liGranular non-standards configuration and tracking/li
+   liImproved authentication framework/li
+   liPlug-in mechanism for authentication modules/li
+   liCookie specification plug-in mechanism/li
+   liCross-site redirect support/li
+  /ul
+ /p
+ p
+  We see our fellow Apache developers as well as other open-source
+  projects already reliant on HttpClient as the primary target
+  audience for this release. This can be the right moment to evaluate
+  HttpClient 3.0 and give us some feedback, critique or thoughts on
+  the new API and file requests for additional features. The goal of
+  the second ALPHA release is to incorporate the feedback, polish the
+  API and update documentation. The next ALPHA release will target the
+  wider audience beyond the Apache Jakarta and Apache WS communities.
+ /p
+ p
+  Please a href=downloads.htmldownload/a and
+  let us know what you think.
+ /p
 /section

 section name=16 April 2004 - Welcome Jakarta HttpClient!
Index: status.xml
===
RCS file: /home/cvspublic/jakarta-commons/httpclient/xdocs/status.xml,v
retrieving revision 1.23
diff -u -r1.23 status.xml
--- status.xml  17 May 2004 03:46:44 -  1.23
+++ status.xml  17 May 2004 11:33:41 -
@@ -18,13 +18,29 @@
 A number of major changes have already been incorporated into the 3.0 code 
base, though
 there is still room for more in the final release.  We would like to encourage
 comment on the API changes and additions made so far./p
-
+p   
+Most noteworthy enhancements include:
+ ul
+  liNew preference architecture/li
+  liImproved exception handling framework/li
+  liGranular non-standards configuration and tracking/li
+  liImproved authentication framework/li
+  liPlug-in mechanism for authentication modules/li
+  liCookie specification plug-in mechanism/li
+  liCross-site redirect support/li
+ /ul
+/p
 pHttpClient 2.0 is no longer being actively developed, with the exception of
 bug fixes.  A 2.0.1 release is planned for the near future./p

pIt is important to note that HttpClient CVS HEAD is no longer fully 
compatible
 with 2.0 APIs. We encourage using the ttHTTPCLIENT_2_0_BRANCH/tt for 
production
- development until the 3.0 APIs are stabilized./p
+ development until the 3.0 APIs are stabilized. API incompatibilities with 
HttpClient
+ 2.0 are described a href=API_CHANGES_3_0.txthere/a.
+/p   
+pBug reports targeted for the next release can be found
+a 
href=http://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=NEWamp;bug_status=ASSIGNEDamp;bug_status=REOPENEDamp;email1=amp;emailtype1=substringamp;emailassigned_to1=1amp;email2=amp;emailtype2=substringamp;emailreporter2=1amp;bugidtype=includeamp;bug_id=amp;changedin=amp;votes=amp;chfieldfrom=amp;chfieldto=Nowamp;chfieldvalue=amp;product=Commonsamp;component=HttpClientamp;target_milestone=3.0+Alpha+2amp;short_desc=amp;short_desc_type=allwordssubstramp;long_desc=amp;long_desc_type=allwordssubstramp;bug_file_loc=amp;bug_file_loc_type=allwordssubstramp;keywords=amp;keywords_type=anywordsamp;field0-0-0=noopamp;type0-0-0=noopamp;value0-0-0=amp;cmdtype=doitamp;newqueryname=amp;order=Reuse+same+sort+as+last+time;here/a.
+/p
 /section

 section name=Release Info


---


-Original Message-
From: Kalnichevski, Oleg
Sent: Monday, May 17, 2004 13:47
To: Commons HttpClient Project
Subject: RE: 3.0 alpha1

RE: 3.0 alpha1 build

[Kalnichevski, Oleg]

Almost forgot. Javadocs need fixing. I'll take care of the problem tonight unless 
someone beats me to it

Oleg


-Original Message-
From: Michael Becke [mailto:[EMAIL PROTECTED]
Sent: Monday, May 17, 2004 6:11
To: Commons HttpClient Project
Subject: 3.0 alpha1 build


I've uploaded the 3.0 alpha1 build to my apache account
http://www.apache.org/~mbecke/httpclient-3.0-alpha1/.  Please have a
look and let me know if I've missed anything.  This release was created
with JDK1.3.1 since it seems that Maven RC2 does not work with 1.2.2. 
I don't think this will cause any issues, but if anyone is using 1.2.2
please give it a shot.  This is also the first time I've signed a
release.  My public key is in the KEYS file so please try that out as
well.

My plan is to finish this off tomorrow night and post the release.  I
was thinking of leaving the 2.0 docs as the main HttpClient page, and
just adding a link to the 3.0 version in another directory.

Mike


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: 3.0 alpha1 build

[Kalnichevski, Oleg]

Javadoc compiler reported 20 some warnings when I ran maven's site generate. Most of 
those warnings seem to be related to the latest changes introduced with the most 
recent patches

Oleg

-Original Message-
From: Michael Becke [mailto:[EMAIL PROTECTED]
Sent: Monday, May 17, 2004 14:44
To: Commons HttpClient Project
Subject: Re: 3.0 alpha1 build


What in the Javadocs needs fixing?

Mike

On May 17, 2004, at 7:58 AM, Kalnichevski, Oleg wrote:


 Almost forgot. Javadocs need fixing. I'll take care of the problem 
 tonight unless someone beats me to it

 Oleg


 -Original Message-
 From: Michael Becke [mailto:[EMAIL PROTECTED]
 Sent: Monday, May 17, 2004 6:11
 To: Commons HttpClient Project
 Subject: 3.0 alpha1 build


 I've uploaded the 3.0 alpha1 build to my apache account
 http://www.apache.org/~mbecke/httpclient-3.0-alpha1/.  Please have a
 look and let me know if I've missed anything.  This release was created
 with JDK1.3.1 since it seems that Maven RC2 does not work with 1.2.2.
 I don't think this will cause any issues, but if anyone is using 1.2.2
 please give it a shot.  This is also the first time I've signed a
 release.  My public key is in the KEYS file so please try that out as
 well.

 My plan is to finish this off tomorrow night and post the release.  I
 was thinking of leaving the 2.0 docs as the main HttpClient page, and
 just adding a link to the 3.0 version in another directory.

 Mike


 -
 To unsubscribe, e-mail: 
 [EMAIL PROTECTED]
 For additional commands, e-mail: 
 [EMAIL PROTECTED]


 ***
 
 The information in this email is confidential and may be legally 
 privileged.  Access to this email by anyone other than the intended 
 addressee is unauthorized.  If you are not the intended recipient of 
 this message, any review, disclosure, copying, distribution, 
 retention, or any action taken or omitted to be taken in reliance on 
 it is prohibited and may be unlawful.  If you are not the intended 
 recipient, please reply to or forward a copy of this message to the 
 sender and delete the message, any attachments, and any copies thereof 
 from your system.
 ***
 

 -
 To unsubscribe, e-mail: 
 [EMAIL PROTECTED]
 For additional commands, e-mail: 
 [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Posting XML over authenticated connection using SSL

[Kalnichevski, Oleg]

 The problem is that your server reports an incorrect Content-Length on
 the 401 Response body.
 Count yourself: It sais 282 bytes. But the response is 283 bytes. (the
 two [0xfffd] sequences are one byte each). Nothing we can do here I fear.

Lee Francis,

I agree with Odi that incorrect Content-Length value appears to be the culprit. I see 
a way to work the problem around, though. However, the workaround is likely to cost 
you some performance. The problem can be solved by not re-using persistent 
connections. If you use HTTP/1.0 or instruct the server to not keep the connection 
alive, all the garbage from the previous request will no longer be in the way of the 
subsequent one

The preferred way to disable persistent connections is to send Connection: close 
directive with the request.

Cheers,

Oleg


-Original Message-
From: Ortwin Glück [mailto:[EMAIL PROTECTED]
Sent: Friday, May 14, 2004 14:42
To: Commons HttpClient Project
Subject: Re: Posting XML over authenticated connection using SSL




Lee Francis Wilhelmsen wrote:
 - The server responds saying not authorized with a realm value
 - HTTP Client then resends the post using the credentitals
   I have supplied (why doesn't it do this the first time?)

This is the standard behaviour. You can enable preemtive authentication.

 org.apache.commons.httpclient.HttpRecoverableException: Error in parsing
 the status  line from the response: unable to find line starting with
 HTTP


 DEBUG [main] httpclient.wire -  HTTP/1.1 401 Unauthorized [\r][\n]
 DEBUG [main] httpclient.wire -  Server: IBM HTTP Server/V5R3M0[\r][\n]
 DEBUG [main] httpclient.wire -  Date: Fri, 14 May 2004 11:18:33
 GMT[\r][\n]
 DEBUG [main] httpclient.wire -  Accept-Ranges: bytes[\r][\n]
 DEBUG [main] httpclient.wire -  Content-Type: text/html;
 charset=IBM-1047[\r][\n]
 DEBUG [main] httpclient.wire -  Content-Length: 282[\r][\n]
 DEBUG [main] httpclient.wire -  Last-Modified: Fri, 14 May 2004
 11:18:33 GMT[\r][\n]
 DEBUG [main] httpclient.wire -  Expires: Fri, 14 May 2004 11:18:33
 GMT[\r][\n]
 DEBUG [main] httpclient.wire -  Pragma: no-cache[\r][\n]
 DEBUG [main] httpclient.wire -  Cache-Control: no-cache[\r][\n]
 DEBUG [main] httpclient.wire -  WWW-Authenticate: Basic
 realm=STING_Restricted[\r][\n]
 DEBUG [main] httpclient.wire -  IMW0254E
 HTMLHEADTITLEError/TITLE/HEADBODY
 bgcolor=[0xfffd][0xfffd]FFF7E7H1Error 401/H1IMW0216E Not
 authorized.  Authentication failed.PHRADDRESSA
 HREF=https://e-torg.no.ihost.com/; target=_topIBM HTTP Server -
 North American Edition V5R3M0/A/ADDRESS/BODY/HTML
 DEBUG [main] httpclient.wire -  POST /sting/StingServlet


 Notice there is no closing  character and this seems to be the cause
 of this particular problem.

 Why is this happening? Can anyone help?

 Best regards
 Lee Francis Wilhelmsen


Lee,

The problem is that your server reports an incorrect Content-Length on
the 401 Response body.
Count yourself: It sais 282 bytes. But the response is 283 bytes. (the
two [0xfffd] sequences are one byte each). Nothing we can do here I fear.

Ortwin Glück

--
  _
  NOSE applied intelligence ag

  ortwin glück  [www]  http://www.nose.ch
  software engineer [email] [EMAIL PROTECTED]
  hardturmstrasse 171   [pgp id]   0x81CF3416
  8005 zürich   [office]  +41-1-277 57 35
  switzerland   [fax] +41-1-277 57 12

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: 'Socket closed' exception using

[Kalnichevski, Oleg]

Sofya,

It does sound dubious. There's no way a new instance of SimpleHttpConnectionManager 
can obtain an existing instance of HttpConnection. SimpleHttpConnectionManager 
*always* creates a new instance of HttpConnection. It is perfectly possible, though, 
that an open connection lingers in memory for some time until garbage collected, since 
SimpleHttpConnectionManager makes no attempts to close connections. However, I do not 
see how this may prompt the WMS to drop another connection used by a totally different 
instance of SimpleHttpConnectionManager, unless there's a bug in the WMS server-side 
connection pool code which causes the pool manager to drop active connections when MAX 
TOTAL is reached. This is a just wild guess on part, though

Since your application makes no attempt to re-use connections, you may want to send 
Connection: close directive with HTTP requests to ensure that the connection is 
immediately closed once the response is consumed. See if that helps circumvent the 
problem.

Hope this helps a little

Oleg

-Original Message-
From: Preygel, Sofya [mailto:[EMAIL PROTECTED]
Sent: Friday, May 14, 2004 16:03
To: Commons HttpClient Project
Subject: RE: 'Socket closed' exception using



Good morning,

I am still working on the 'socket connection' problem. According to the
Connotate tech support a possible reason of getting this exception is
that the connection is not being closed on the client, but instead,
released to the pool:

The socket closure is happening on the WMS side.  That is, since the
connection is not being closed on the client side between each
invocation, the server eventually enters an invalid state and forcibly
closes the connection.  When that happens depends on a number of things
and would appear to be almost random from the client point of view... A
verification of the connection pooling behavior or a test run with code
that guarantees closure of the connection would be needed to eliminate
it. 

I am doubtful of this explanation. I create a new HTTPClient object for
each request (using the SimpleHttpConnectionManager object), and looking
through the HTTPClient code I do not see how the connection can be
re-used in such situation. Yet you guys and the guys at Connotate
certainly know this subject better than I do, and I  an eager to try
everything. My question is: does this explanation seem plausible to you?
If yes, what would be the way to force-close the connection after the
request? Can I do this using the connection: close header params?

Thank you,
Sofya



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Persistent HTTPS connections

[Kalnichevski, Oleg]

John,

Please correct me if I am wrong (which may well be the case) SO_TIMEOUT only affects 
socket read operations. I thought it had nothing to do with SSL inactivity timeout. 
But it looks like it might.

There's another way to deal with recoverable exceptions. You can provide a custom 
implementation of MethodRetryHandler

http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/httpclient/MethodRetryHandler.html

The default implementation of the MethodRetryHandler is quite conservative. It does 
not allow the method to be retried if the request has been transmitted in its 
entirety. 

http://jakarta.apache.org/commons/httpclient/xref/org/apache/commons/httpclient/DefaultMethodRetryHandler.html#62

Oleg


-Original Message-
From: Jesus M. Salvo Jr. [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 13, 2004 7:40
To: [EMAIL PROTECTED]
Subject: Persistent HTTPS connections



Using HttpClient 2.0
JDK 1.4.2_04 on Fedora

Is there anything special that I have to do to make use of persistent
HTTP(S) connections with HttpClient other than using
MultiThreadedHttpConnectionManager ?

Basically, what I am doing is the following ( more explanation after the
snippet of the source code ):

MultiThreadedHttpConnectionManager connectionManager =
  new MultiThreadedHttpConnectionManager();
connectionManager.setConnectionStaleCheckingEnabled( true );
connectionManager.setMaxConnectionsPerHost( 10 );
connectionManager.setMaxTotalConnections( 100 );

this.httpClient = new HttpClient( connectionManager );
this.httpClient.setConnectionTimeout( 3 );
this.httpClient.setTimeout( 3 );

 and then within a thread, the thread does this:

  String content;
  HttpMethod method;
   
try {
  method = new PostMethod( connectionURL );
   
  method.setDoAuthentication( true );
  method.setRequestHeader( Content-Type, contentType + ;
charset= + this.outboundEncoding);
  if( method instanceof PostMethod ) {
PostMethod postMethod = (PostMethod) method;
postMethod.setRequestBody( content );
  }
   int responseCode = this.httpClient.executeMethod( method );
   String response = method.getResponseBodyAsString();
   .
}
catch( Exception ex ) {}
finally {
   if( method != null ) method.releaseConnection();
}


What I am doing, then, from a JUnit test class, is:

1) Send one HTTP POST to a URL, which works and I get the response.
2) Sleep for 40 seconds ( which is greater than the SO_TIMEOUT of 30
seconds )
3) Send another HTTP POST to the same URL.

What I am seeing with ethereal is that, after 30 seconds of no activity
( no TCP ACKs whatever on the socket ), the web server sends a a TLS alert.
So what actually happens is this:


1) Send one HTTP POST to a URL, which works and I get the response.
2) Sleep for 40 seconds ( which is greater than the SO_TIMEOUT of 30
seconds )
3) Web server sends a TLS alert after 30 seconds of inactivity. Web
server sends a TCP FIN, Java sends a TCP ACK _only_ .
4) Wake up from sleep at the 40 second mark, send another HTTP POST to
the same URL.
5) Receive a TLS alert instead of a HTTP response. The TLS alert
according to JSSE's debug mode is:
main, RECV TLSv1 ALERT:  warning, close_notify
main, called closeInternal(false)
main, SEND TLSv1 ALERT:  warning, description = close_notify
6) HttpClient throws an HttpRecoverableException, shown below:

org.apache.commons.httpclient.HttpRecoverableException:
org.apache.commons.httpclient.HttpRecoverableException: Error in parsing
the status  line from the response: unable to find line starting with HTTP

Question is, was I correct in initially assuming that
MultiThreadedHttpConnectionManager should have handled this case ?
e.g... .detected that the exception, and retried the HTTP POST by
creating a new HTTPS socket ?




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL 

RE: redirect issue with httpclient

[Kalnichevski, Oleg]

Himanshu,
HttpClient 2.0, unfortunately, cannot automatically handle cross-host redirects. But 
this limitation is not difficult to work around. See the document below

http://jakarta.apache.org/commons/httpclient/redirects.html

HttpClient 3.0 will address this limitation

Oleg

-Original Message-
From: Himanshu Pathak [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 13, 2004 10:08
To: [EMAIL PROTECTED]
Subject: redirect issue with httpclient


  hi all,

I am using Jakarta HTTPClient to do a post on a website.
it seems that after the authentication the page is getting redirected to
other location.
the significant thing is that its changing the port also.

below i am posting the output i am getting from my code.

May 13, 2004 12:43:25 PM org.apache.commons.httpclient.HttpMethodBase
readResponseBody
WARNING: Response content length is not known
May 13, 2004 12:43:29 PM org.apache.commons.httpclient.HttpMethodBase
readResponseBody
WARNING: Response content length is not known
May 13, 2004 12:43:29 PM org.apache.commons.httpclient.HttpMethodBase
processRedirectResponse
INFO: Redirect requested but followRedirects is disabled
STATUS CODE = 302
May 13, 2004 12:43:32 PM org.apache.commons.httpclient.HttpMethodBase
readResponseBody
WARNING: Response content length is not known
May 13, 2004 12:43:32 PM org.apache.commons.httpclient.HttpMethodBase
processRedirectResponse
WARNING: Redirect from port 2048 to 2096 is not supported*
*

how can i make httpclient to get redirected to the new location
automatically.


here is my code:


import org.apache.commons.httpclient.Cookie;
import org.apache.commons.httpclient.cookie.CookiePolicy;
import org.apache.commons.httpclient.Header;
import org.apache.commons.httpclient.HttpClient;
import org.apache.commons.httpclient.HttpStatus;
import org.apache.commons.httpclient.NameValuePair;
import org.apache.commons.httpclient.methods.GetMethod;
import org.apache.commons.httpclient.methods.PostMethod;

public class FormLoginDemo
{
static final String LOGON_SITE = www.somedomain.com;
static final intLOGON_PORT = 2048;
static final String PROXY_HOST = 192.168.10.1;
static final int PROXY_PORT = 80;
  
public static void main(String[] args) throws Exception
{
HttpClient client = new HttpClient();
client.getHostConfiguration().setHost(LOGON_SITE, LOGON_PORT,
http);
  
client.getHostConfiguration().setProxy(PROXY_HOST,PROXY_PORT);
client.getState().setCookiePolicy(CookiePolicy.COMPATIBILITY);
  
GetMethod authget = new GetMethod(/login);
   
client.executeMethod(authget);
Header location = authget.getResponseHeader(Location);
authget.releaseConnection();
  
PostMethod authpost= new PostMethod(/login);
authpost.setFollowRedirects(true);
NameValuePair action   = new NameValuePair(action, login);
NameValuePair url  = new NameValuePair(url, someurl);
NameValuePair userid   = new NameValuePair(user, myuser);
NameValuePair password = new NameValuePair(pass, mypassword);
authpost.setRequestBody( new NameValuePair[] {action, url,
userid, password});
  
client.executeMethod(authpost);
authpost.releaseConnection();

int statuscode = authpost.getStatusCode();
  
System.out.println(STATUS CODE = +statuscode);
  
if ((statuscode == HttpStatus.SC_MOVED_TEMPORARILY) ||
(statuscode == HttpStatus.SC_MOVED_PERMANENTLY) ||
(statuscode == HttpStatus.SC_SEE_OTHER) ||
(statuscode == HttpStatus.SC_TEMPORARY_REDIRECT))
{
Header header = authpost.getResponseHeader(location);
if (header != null)
{
String newuri = header.getValue();
if ((newuri == null) || (newuri.equals()))
newuri = /;
GetMethod redirect = new GetMethod(newuri);
client.executeMethod(redirect);
redirect.releaseConnection();
}
else
{
System.out.println(Invalid redirect);
System.exit(1);
}
}
}
}

any help in this context will be highly appreciated.


Regards.

Himanshu.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or 

RE: HttpClient initialization, when/where?

[Kalnichevski, Oleg]

Duzayak (I hope I got your name right),

You can create an instance of the HttpState class per thread and pass the respective 
HttpState object along with the HTTP method to be executed:

// shared by all the worker threads
HttpConnectionManager connman = new MultiThreadedHttpConnectionManager();
HttpClient agent = new HttpClient(connman);

// one per thread
HttpState httpstate = new HttpState();

// in the worker thread
GetMethod httpget = new GetMethod(http://www.whatever.com;);
try {
  agent.executeMethod(null, httpget, httpstate);
  // do something useful with the result
} finally {
  httpget.releaseConnection();
}


For more details see

http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/httpclient/HttpClient.html#executeMethod(org.apache.commons.httpclient.HostConfiguration,%20org.apache.commons.httpclient.HttpMethod,%20org.apache.commons.httpclient.HttpState)

HTH

Oleg

-Original Message-
From: Cabbar Duzayak [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 12, 2004 9:33
To: [EMAIL PROTECTED]
Subject: HttpClient initialization, when/where?


Hi,

I will be writing a gateway which will invoke URLs in
behalf of several threads and they will return the
content. Each thread needs to invoke different URLs
with different context (cookies, etc).

It looks like right way of doing this is to
instantiate the HttpClient once with
MultiThreadedHttpConnectionManager and each thread
will use httpClient.executeMethod on this HttpClient
instance. Or the other alternative is to instantiate
one object for each thread, and keep calling
executeMethods on them.

However, since you can set the state of the
HttpClient, I was wondering if I can use the
HttpClient for iterative http invocations with
different contexts? I mean, is there an in-memory
state other than the HttpState that is preserved
between these invocations? Would it be enough to
create an HttpState and GetMethod for each call, and
set it before calling executeMethod?

Shortly, what is the optimum mechanism for this
functionality?

TIA...





__
Do you Yahoo!?
Yahoo! Movies - Buy advance tickets for 'Shrek 2'
http://movies.yahoo.com/showtimes/movie?mid=1808405861

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Cookie Bug?

[Kalnichevski, Oleg]

Duzayak,

'Set-Cookie' (request) header is not the same thing as the 'Cookie' (response) header. 
CookieSpec#formatCookieHeader() method produces a 'Set-Cookie' (request) header, 
whereas CookieSpec#parse() method is intended to parse 'Cookie' (response) headers

I hope this clarifies things a bit

Oleg

-Original Message-
From: Cabbar Duzayak [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 12, 2004 13:47
To: Commons HttpClient Project
Subject: Cookie Bug?


Hi,

I am trying to run the following code for
www.google.com:

Cookie cookie = initialState.getCookies()[0];
CookieSpec cs = CookiePolicy.getDefaultSpec();
Header h = cs.formatCookieHeader(cookie);
Cookie[] cookie2 = cs.parse(cookie.getDomain(), 80,
cookie.getPath(), cookie.getSecure(), h);

And, it is throwing an exception as:

org.apache.commons.httpclient.cookie.MalformedCookieException:
Cookie name may not start with $

It looks like h.getValue returns name with $ sign
(which was indeed created by the cookiespec), but the
same cookiespec can not read this back, because it has
a $ sign???

BTW, h.getValue() is:

$Version=0;
PREF=ID=069e080d47cd4332:TM=1084362072:LM=1084362072:S=0u9G4CTYGPvhxJzn;
$Domain=.google.com; $Path=/

Looks like, cookieSpec.parse is expecting the same
string without $ signs, in fact, when I remove dollar
signs manually, the code works fine.

Did I hit the jackpot and found a bug;)

Thanks...





__
Do you Yahoo!?
Yahoo! Movies - Buy advance tickets for 'Shrek 2'
http://movies.yahoo.com/showtimes/movie?mid=1808405861

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[VOTE][RESULT] Migrate HttpClient issue tracking from Bugzilla to Jira

[Kalnichevski, Oleg]

HttpClient project voted in favour of migration from Bugzilla to Jira

+1 votes -

 Jeff Dever jsdever -at- apache.org
 Ortwin Glück oglueck -at -apache.org
 Adrian Sutton adrian -at- apache.org
 Oleg Kalnichevski olegk -at- apache.org
 Michael Becke mbecke -at- apache.org

***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [VOTE][RESULT] Migrate HttpClient issue tracking from Bugzilla to Jira

[Kalnichevski, Oleg]

Folks

I have filed a request with the infrastructure to migrate HttpClient issue tracking 
from Bugzilla to Jira

http://nagoya.apache.org/jira/browse/INFRA-74

I hope we'll get luckier this time around

Oleg

***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: A few remaining issues to be discussed before we cut 3.0a1

[Kalnichevski, Oleg]

 As you know, I have a very relaxed oppinion of breaking API
 compatibility. I am in favour of this change.

Same here. But I have to admit we might be a minority on this issue

 Anything I can help here?

Only to help me drown my frustration in a few beers ;-) On a more serious note, I do 
not think there's much we can do. Our only option is to vote in favour of migration to 
Jira and hope that Jira is better supported

Oleg

-Original Message-
From: Ortwin Glück [mailto:[EMAIL PROTECTED]
Sent: Monday, May 10, 2004 9:48
To: Commons HttpClient Project
Subject: Re: A few remaining issues to be discussed before we cut 3.0a1


Oleg Kalnichevski wrote:
 (1) Since this release is going to be incompatible with 2.0 API anyways,
 I suggest HttpException be changed to derive from Exception and not
 IOException.

As you know, I have a very relaxed oppinion of breaking API
compatibility. I am in favour of this change.


 (2) I no longer want to conceal my frustration with the way bugzilla is
 managed. Frankly I am fed up. I suggest we seriously consider moving to
 Jira. 

Anything I can help here?


--
  _
  NOSE applied intelligence ag

  ortwin glück  [www]  http://www.nose.ch
  software engineer [email] [EMAIL PROTECTED]
  hardturmstrasse 171   [pgp id]   0x81CF3416
  8005 zürich   [office]  +41-1-277 57 35
  switzerland   [fax] +41-1-277 57 12

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[VOTE] Migrate HttpClient issue tracking from Bugzilla to Jira

[Kalnichevski, Oleg]

Please vote as follows:

-
 Vote:  Migrate HttpClient issue tracking from Bugzilla to Jira
 [ ] +1 I am in favor of the proposal, and will help support it.
 [ ] +0 I am in favor of the proposal, but am unable to help support it.
 [ ] -0 I am not in favor of the proposal.
 [ ] -1 I am against this proposal (must include a reason).
  
-

Migration process is described here

http://nagoya.apache.org/wiki/apachewiki.cgi?JIRABugzillaMigration

Oleg

***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [VOTE] Migrate HttpClient issue tracking from Bugzilla to Jira

[Kalnichevski, Oleg]

+1

-Original Message-
From: Kalnichevski, Oleg
Sent: Monday, May 10, 2004 11:03
To: Commons HttpClient Project
Subject: [VOTE] Migrate HttpClient issue tracking from Bugzilla to Jira



Please vote as follows:

-
 Vote:  Migrate HttpClient issue tracking from Bugzilla to Jira
 [x] +1 I am in favor of the proposal, and will help support it.
 [ ] +0 I am in favor of the proposal, but am unable to help support it.
 [ ] -0 I am not in favor of the proposal.
 [ ] -1 I am against this proposal (must include a reason).
 

-

Migration process is described here

http://nagoya.apache.org/wiki/apachewiki.cgi?JIRABugzillaMigration

Oleg

***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: keep-alive with HTTPS

[Kalnichevski, Oleg]

Hi John,

The problem is caused by a bug in older Sun's JSSE implementations. Indeed, it has 
nothing to do with HttpURLConnection.

The problem is actually an interplay of several factors

(1) Persistent connections.

HttpClient attempts to reuse HTTP connections whenever possible.

(2) 'Stale' connections check

According to the HTTP spec HTTP connection can be dropped either by the server or by 
the client at any time without giving any notice. So, at any point in time persistent 
HTTP connection may become unusable (or stale). The only reliable way to tell if the 
connection is still open on both ends (we know of) is to perform an I/O operation on 
the socket. Prior to executing a method HttpClient attempts to do a short (one 
millisecond) read on the underlying socket in order to ensure that the connection is 
still good. This is what we call a stale connection check

(3) JSSE bug

Older versions of Sun JSSE do not handle timeouts correctly. A one millisecond read 
operation on a perfectly useable SSL socket results in 'end of stream' condition 
(socket closed) instead of a timeout exception as expected. This bug causes the stale 
connection check to produce erroneous result, which in its turn causes HttpClient to 
drop the connection.

There are two possibilities to work the problem around

* upgrade to JDK 1.4 or newer that does not exhibit the problem
* disable the stale connection check

I hope this makes the situation somewhat clearer for you

Oleg




-Original Message-
From: Jesus M. Salvo Jr. [mailto:[EMAIL PROTECTED]
Sent: Monday, May 10, 2004 8:41
To: [EMAIL PROTECTED]
Subject: keep-alive with HTTPS



I was re-reading the SSL guide today and it mentions about *Persistent
SSL connections do not work on Sun's JVMs below 1.4.*
However, the details for that section is actually talking about HTTP
keep-alive ( and then talks about stale SSL connections ).

So I am a bit confused now. Is / Was the problem with the JVM itself (
that is, with HttpURLConnection ), or was it with JSSE ?
Since HttpClient is creating its own socket ( and does not use Java's
URLConnection ), then the problem with HTTP keep-alive should not
affected HttpClient
( assuming it was a problem with HttpURLConnection ).

Reason I ask is that we are still running JDK 1.3.1_08 on Solaris SPARC.

Anyway, I'm still confused.
Anyone care to enlighten me ?

Thanks

John









-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: MultiThreadedConnectionManager based on commons pool

[Kalnichevski, Oleg]

Andrea,

New HttpClient 3.0 API has not been properly documented yet (documentation and test 
case coverage will become a top priority right after the 3.0-alpha1 release). The idle 
connection management with the multi-threaded connection manager does take a little 
bit of explaining. Per default the connection manager does not attempt to close idle 
connections as before. It simply provides the user with the means to handle idle 
connections the way the user sees fit. There's a new method in the 
HttpConnectionManager interface called #closeIdleConnections(long) intended to advise 
the connection manager to drop those connections that have been idle for the specified 
period of time. This method can be invoked either from the main communication thread 
during a period of inactivity or from a dedicated  monitor thread on a regular basis. 
The helper class IdleConnectionTimeoutThread can be used to easily set up a simple 
idle connection monitor. The reason for not running a dedicated idle connection 
monitor per default is to keep HttpClient usable in an EJB container. The EJB spec 
requires that enterprise beans do no explicit thread management.

Give the new features another shot. They may still prove not that bad

I just had the first cursory look at your commons-pool based implementation. It looks 
very promising but the code currently requires a few tweaks to be compatible with 3.0 
API.

Oleg


-Original Message-
From: Andrea Fabris [mailto:[EMAIL PROTECTED]
Sent: Friday, May 07, 2004 10:08
To: Commons HttpClient Project
Subject: Re: MultiThreadedConnectionManager based on commons pool


Thanks for your feedback!

Now i'll explain my thoughts about multithreaded manager.

The biggest problem tha manger has, is about the idle connection status:
for a long time now, as stated by a lot of people, idle connections
where not handled well, because they remain in CLOSE_WAIT status when
returned from the client to the pool until some client requests them back.
This is a waste of resources.
Now, after i noticed the bugzilla 25372 (is it closed, right now? I have
some problems accessing CVS...), i downloaded the latest nigthly build
and made a few test, but i discovered that the problem remains.
So i thought it would be easier to change the logic of the manager and
to base it on a pool library that is known to work.

However, i see your point of view: it would be desiderable to limit the
httpclient dependencies only to those libraries that are a must (eg:
logging).

By the way, as stated by oleg, i'm goig to sign the Apache CLA and
document better the code i attached in my prevoius mail, hoping that
this code could be useful in the contrib branch.

Regards
Andrea Fabris
Errore Apertura DB

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: SSLHandshakeException: No trusted certificate found

[Kalnichevski, Oleg]

Thorsten,
There are currently two branches of HttpClient: stable (2.0) and development (that 
will eventually become 3.0). Apparently you got hold of code from the development 
branch. Try the following link instead:

http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/ssl/?only_with_tag=HTTPCLIENT_2_0_BRANCH

Oleg


-Original Message-
From: Thorsten Scherler
[mailto:[EMAIL PROTECTED]
Sent: Friday, May 07, 2004 12:04
To: Commons HttpClient Project
Subject: Re: SSLHandshakeException: No trusted certificate found


Hi Oleg,

thanks a million for the link! ...but one question the
EasySSLProtocolSocketFactory.java is refering to which version of the
http-client? I am using 2.0 (bin) and the following imports cannot be
resolved:
import org.apache.commons.httpclient.ConnectTimeoutException;
import org.apache.commons.httpclient.HttpClientError;
import org.apache.commons.httpclient.params.HttpConnectionParams;
import org.apache.commons.httpclient.protocol.ControllerThreadSocketFactory;
import org.apache.commons.httpclient.protocol.ReflectionSocketFactory;

Thanks again!
King regards
Thorsten

Kalnichevski, Oleg wrote:

Hi Thorsten

Have a look at the 'Customizing SSL' section of the HttpClient SSL guide 
http://jakarta.apache.org/commons/httpclient/sslguide.html

Oleg

-Original Message-
From: Thorsten Scherler
[mailto:[EMAIL PROTECTED]
Sent: Friday, May 07, 2004 11:26
To: Commons HttpClient Project
Subject: SSLHandshakeException: No trusted certificate found


Hello group,

I have a problem with ssl. I am monitoring different services with a
server. Now I have a service that throws exceptions:
https://desafirma.cjap.junta-andalucia.es

The reason is a No trusted certificate found. If I try
https://www.sun.com everything is fine because it is a trusted one.

I found the following thread:
http://forum.java.sun.com/thread.jsp?thread=515154forum=2message=2454974
...but how can I incorporate that in my HTTP-Client?

Thanks for any ideas, links or solutions.

King regards
Thorsten

Code that I use:
import java.io.IOException;

import org.apache.commons.httpclient.HttpMethod;
import org.apache.commons.httpclient.HttpRecoverableException;
import org.apache.commons.httpclient.methods.GetMethod;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

/**
 * @author Thorsten Scherler
 * @mail [EMAIL PROTECTED]
 *
 */
public class HttpClient implements HttpClientInterface {
private static Log LOG = LogFactory.getLog(HttpClient.class);
public String getHttp(String address, int timeout) throws Exception {
//Create an instance of HttpClient.
org.apache.commons.httpclient.HttpClient client =
new org.apache.commons.httpclient.HttpClient();
if (LOG.isDebugEnabled())
LOG.debug(-Sonda-SONAR-HttpClient-START);
//initialize parameter
String url = null;
//test whether a protocol prefix exist
String protocol = http://;;
String protocolS = https://;;
if (address.indexOf(protocol)  -1
|| address.indexOf(protocolS)  -1) {
url = address;
} else {
url = protocol + address;
}
//DEBUG: Parameter testing
if (LOG.isDebugEnabled())
LOG.debug(-Sonda-SONAR-HttpClient-address- + address);
if (LOG.isDebugEnabled())
LOG.debug(-Sonda-SONAR-HttpClient-URL-+url);

//establish a connection within 5 seconds
client.setConnectionTimeout(timeout);
// Create a method instance.
HttpMethod method = new GetMethod(url);
//Follow redirects
method.setFollowRedirects(false);
//Mask the client
//Win
//method.setRequestHeader(
//user-agent,
//Mozilla/5.0 (Windows; U; Windows NT 5.0; en - US;
rv : 1.6) Gecko / 20040113 );
//Linux
method.setRequestHeader(
user-agent,
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1)
Gecko/20021);
//Execute the method.
int statusCode = -1;
//We will retry up to 3 times.
for (int attempt = 0; statusCode == -1  attempt  3; attempt++) {
try {
// execute the method.
statusCode = client.executeMethod(method);
} catch (IOException e) {
if (LOG.isErrorEnabled())
LOG.error(Failed to download file., e);
if (LOG.isDebugEnabled())
LOG.debug(-Sonda-SONAR-HttpClient-END);
return 666;
}
}
// Check that we didn't run out of retries.
//If so reply with a fake http-code,
//666 is not a valid HTTP code, it was choosen because of that ;-)
if (statusCode == -1) {
if (LOG.isErrorEnabled())
  
LOG.error(-Sonda-SONAR-HttpClient-ERROR-FAILED

RE: MultiThreadedConnectionManager based on commons pool

[Kalnichevski, Oleg]

Andrea,

Both 2.0  CVS HEAD nightlies are available 
http://jakarta.apache.org/commons/httpclient/downloads.html.

This may sound a bit harsh, but I _personally_ do not see 2.0 API worthwhile of any 
further development. As useful as it is HttpClient 2.0 API is fundamentally flawed in 
many ways. HttpClient 3.0 will resolve many of the known problems 
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/release_notes.txt?rev=1.21view=markup
 and will render 2.0 completely obsolete. Again, this is just my personal (humble) 
opinion. As long as there's substantial interest in HttpClient 2.0, it will be 
supported. However, I do think all new development should take place in CVS HEAD.

Oleg

-Original Message-
From: Andrea Fabris [mailto:[EMAIL PROTECTED]
Sent: Friday, May 07, 2004 12:06
To: Commons HttpClient Project
Subject: Re: MultiThreadedConnectionManager based on commons pool


On 07/05/2004 10.38, Kalnichevski, Oleg wrote:

 Andrea,

 New HttpClient 3.0 API has not been properly documented yet (documentation and test 
 case coverage will become a top priority right after the 3.0-alpha1 release). The 
 idle connection management with the multi-threaded connection manager does take a 
 little bit of explaining. Per default the connection manager does not attempt to 
 close idle connections as before. It simply provides the user with the means to 
 handle idle connections the way the user sees fit. There's a new method in the 
 HttpConnectionManager interface called #closeIdleConnections(long) intended to 
 advise the connection manager to drop those connections that have been idle for the 
 specified period of time. This method can be invoked either from the main 
 communication thread during a period of inactivity or from a dedicated  monitor 
 thread on a regular basis. The helper class IdleConnectionTimeoutThread can be used 
 to easily set up a simple idle connection monitor. The reason for not running a 
 dedicated idle con
nection monitor per default is to keep HttpClient usable in an EJB container. The EJB 
spec requires that enterprise beans do no explicit thread management.

 Give the new features another shot. They may still prove not that bad

 I just had the first cursory look at your commons-pool based implementation. It 
 looks very promising but the code currently requires a few tweaks to be compatible 
 with 3.0 API.


 Oleg

Well, i thought the patch was for 2.0 branch, not 3.0!!! (i have to
admit that i gave only a fast look at the bugzilla reports on the list,
'cause i had a lot of work to do.. ;-) )
In fact i developed the code from the official 2.0 code!

However, i'll try to download the source from cvs, and compile it.. i
think that the nightly builds are from 2.0 branch, or not?

By the way, if you need further information about my code, feel free to ask

Cheers
Andrea
Errore Apertura DB

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: SSLHandshakeException: No trusted certificate found

[Kalnichevski, Oleg]

 By the way the
 http://jakarta.apache.org/commons/httpclient/sslguide.html is NOT really for the 2.0 
 Branch, or is it?
 The line: httpclient.getHostConfiguration().setHost(www.whatever.com, 443, 
 myhttps);

Thorsten,

The code snippets inside the SSL guide should be compilable against HttpClient 2.0. 
However, the links to the CVS repository apparently point to the wrong branch. I'll 
take of the problem tonight

Oleg

-Original Message-
From: Thorsten Scherler
[mailto:[EMAIL PROTECTED]
Sent: Friday, May 07, 2004 13:26
To: Commons HttpClient Project
Subject: Re: SSLHandshakeException: No trusted certificate found


Thx Oleg,

I got it running :)

Short summary:
1) download

EasySSLProtocolSocketFactory.java  
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/ssl/EasyX509TrustManager.java?only_with_tag=HTTPCLIENT_2_0_BRANCH
EasyX509TrustManager.java 
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/ssl/EasyX509TrustManager.java?only_with_tag=HTTPCLIENT_2_0_BRANCH

from

http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/ssl/?only_with_tag=HTTPCLIENT_2_0_BRANCH

2) add:
//NOT trusted SSL
Protocol myhttps = new Protocol(https, new EasySSLProtocolSocketFactory(), 443);
Protocol.registerProtocol(https, new Protocol(https, new 
EasySSLProtocolSocketFactory(), 443));
HttpClient httpclient = new HttpClient();
//... from there old school
3) cross your finger ;-)
-
By the way the
http://jakarta.apache.org/commons/httpclient/sslguide.html is NOT really for the 2.0 
Branch, or is it?
The line: httpclient.getHostConfiguration().setHost(www.whatever.com, 443, myhttps);

is raising the Error: method getHostConfiguration() is undefined for the typ 
httpclient.

Thank you very much (again) Oleg! You are always a great help!
Cheers!

King regards
Thorsten


Kalnichevski, Oleg wrote:

Thorsten,
There are currently two branches of HttpClient: stable (2.0) and development (that 
will eventually become 3.0). Apparently you got hold of code from the development 
branch. Try the following link instead:

http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/ssl/?only_with_tag=HTTPCLIENT_2_0_BRANCH

Oleg


-Original Message-
From: Thorsten Scherler
[mailto:[EMAIL PROTECTED]
Sent: Friday, May 07, 2004 12:04
To: Commons HttpClient Project
Subject: Re: SSLHandshakeException: No trusted certificate found


Hi Oleg,

thanks a million for the link! ...but one question the
EasySSLProtocolSocketFactory.java is refering to which version of the
http-client? I am using 2.0 (bin) and the following imports cannot be
resolved:
import org.apache.commons.httpclient.ConnectTimeoutException;
import org.apache.commons.httpclient.HttpClientError;
import org.apache.commons.httpclient.params.HttpConnectionParams;
import org.apache.commons.httpclient.protocol.ControllerThreadSocketFactory;
import org.apache.commons.httpclient.protocol.ReflectionSocketFactory;

Thanks again!
King regards
Thorsten

Kalnichevski, Oleg wrote:

 

Hi Thorsten

Have a look at the 'Customizing SSL' section of the HttpClient SSL guide 
http://jakarta.apache.org/commons/httpclient/sslguide.html

Oleg

-Original Message-
From: Thorsten Scherler
[mailto:[EMAIL PROTECTED]
Sent: Friday, May 07, 2004 11:26
To: Commons HttpClient Project
Subject: SSLHandshakeException: No trusted certificate found


Hello group,

I have a problem with ssl. I am monitoring different services with a
server. Now I have a service that throws exceptions:
https://desafirma.cjap.junta-andalucia.es

The reason is a No trusted certificate found. If I try
https://www.sun.com everything is fine because it is a trusted one.

I found the following thread:
http://forum.java.sun.com/thread.jsp?thread=515154forum=2message=2454974
...but how can I incorporate that in my HTTP-Client?

Thanks for any ideas, links or solutions.

King regards
Thorsten

Code that I use:
import java.io.IOException;

import org.apache.commons.httpclient.HttpMethod;
import org.apache.commons.httpclient.HttpRecoverableException;
import org.apache.commons.httpclient.methods.GetMethod;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

/**
* @author Thorsten Scherler
* @mail [EMAIL PROTECTED]
*
*/
public class HttpClient implements HttpClientInterface {
   private static Log LOG = LogFactory.getLog(HttpClient.class);
   public String getHttp(String address, int timeout) throws Exception {
   //Create an instance of HttpClient.
   org.apache.commons.httpclient.HttpClient client =
   new org.apache.commons.httpclient.HttpClient();
   if (LOG.isDebugEnabled())
   LOG.debug(-Sonda-SONAR-HttpClient-START);
   //initialize parameter
   String url = null;
   //test

RE: MultiThreadedConnectionManager based on commons pool

[Kalnichevski, Oleg]

Andrea,
HttpClient 2.0 implements connect timeout using a controller thread. This means when 
running HttpClient 2.0 in a EJB container one MAY NOT use 
HttpClient#setConnectionTimeout(int). This problem has been partially solved in the 
CVS HEAD. HttpClient 3.0 when running in 1.4 JRE will use reflection to invoke 1.4 
Socket#connect(SocketAddress, int) instead of using a controller thread

Oleg



-Original Message-
From: Andrea Fabris [mailto:[EMAIL PROTECTED]
Sent: Friday, May 07, 2004 13:17
To: Commons HttpClient Project
Subject: Re: MultiThreadedConnectionManager based on commons pool


Thanks, Oleg.
I've just downloaded the 3.0 latest build, and i'll take a look at it
and how it solves the idle connection problem.

Right now, i need a way to use multithread with httpclient 2.0 (that is
stable), so i think i'll use the code i've sent (because, as you said,
the patch was applied to the 3.0 branch)

However, i see that it is very important to follow the EJB spec so
httpclient could be used in an EJB container (that is, my solution is
not compatible with EJB spec).
I would like to ask you something about it: are there some other points
(other than http pooling) where httpclient has to be rewritten to be
compatible with EJB spec?

Regards
Andrea

On 07/05/2004 12.53, Kalnichevski, Oleg wrote:
 Andrea,

 Both 2.0  CVS HEAD nightlies are available 
 http://jakarta.apache.org/commons/httpclient/downloads.html.


 This may sound a bit harsh, but I _personally_ do not see 2.0 API worthwhile of any 
 further development. As useful as it is HttpClient 2.0 API is fundamentally flawed 
 in many ways. HttpClient 3.0 will resolve many of the known problems 
 http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/release_notes.txt?rev=1.21view=markup
  and will render 2.0 completely obsolete. Again, this is just my personal (humble) 
 opinion. As long as there's substantial interest in HttpClient 2.0, it will be 
 supported. However, I do think all new development should take place in CVS HEAD.

 Oleg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: MultiThreadedConnectionManager based on commons pool

[Kalnichevski, Oleg]

Hi Andrea

I (all of us, I suppose) are very glad that you find HttpClient useful.

The commons-pool is a great and well tested library by itself. No discussion about 
that. However, we should be very selective about external dependencies. This issue 
would not be taken lightly. There are enough folks out there (me included) who 
dislike/do not use otherwise cool libraries with lots of external dependencies.

Per default HttpClient uses single-connection connection manager version and that is 
not likely to change in the foreseeable future. Therefore I _personally_ tend to see 
commons-pool dependency as unjustified. This said, we'd be glad to have your code 
included into HttpClient 'contrib' package of optional components. Besides, we see 
HttpClient in the future evolve from a client-side HTTP agent library to a platform 
agnostic toolkit with a highly modular architecture, which can be used to rapidly 
assemble HTTP agents, crawlers, proxy and light-weight embeddable servers. At that 
point the decision about dependency on commons-pool could be revisited.

Is there anything you particularly dislike about the multi-threaded connection 
manager, besides idle connections issue (which has been resolved, and solved well, at 
least IMHO)? Please let us know. We'll do try to address your concerns.

Please also consider signing the Apache CLA http://www.apache.org/licenses/#clas. 
The Project Management Committee tends to be MUCH, MUCH more strict about accepting 
code contributions these days, especially if you would like to be mentioned as the 
author of the code you contribute

Cheers,

Oleg


-Original Message-
From: Andrea Fabris [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 06, 2004 15:11
To: Commons HttpClient Project
Subject: MultiThreadedConnectionManager based on commons pool


Hello Everybody!
I'm Andrea from italy, and i'm very interested about the jakarta httpclient.
I tried it and i find it very easy to use, but i found (i wrote about it
some time ago) a bug in the multithredconnectionmanger.
It seems that the opened connections are tested for closure only when
they ahve to be given back from the pool to the client. In this way,
after some time where the connections are not used, the connections are
still open but the are in CLOSE_WAIT state: they are shut down when a
client request for a new connection form the pool, but the pool finds
the old conenction in a CLOSE_WAIT state, so it shuts down the
conenction and creates a new one.
Now, int this manner there could be a wate of resources, if nobody uses
connections for a long time.
I have seen that something has been done (in cvs) about auto closing
idle connection, but i still think that the multithreaded connection
manager needs a reimplementation.
I think that could be a great idea to reimplement the manager using
commons pool as a base.
Simply, the manager has to trak a list of open pools based on
GenericObjectPool: every pool in the manager (one for each host) must be
created using a factory that manages the connection life-cycle in the
pool (in the common pool framework).
I attach the code i've written, so you can take a look at it.

Regards
Andrea Fabris

Errore Apertura DB

***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: IIS (NTLM) + proxy server (NTLM or basic) problem

[Kalnichevski, Oleg]

Lili,
There's nothing in the log that could suggest a flaw in HttpClient's authentication 
logic. Everything appears sane as far as the authentication is concerned. Proxy 
authentication was successful. The trouble appears to be caused by the NTLM host 
server which does not seem to accept the credentials.

client.getState().setCredentials(
null,
10.8.9.22,
new NTCredentials(lliu, x, 10.8.9.22, INXIGHT)
);

(1) Please double-check the domain name and try using the host name (every NT box must 
have one) instead of the IP (10.8.9.22) in the NTCredentials constructor.

client.getState().setCredentials(
null,
10.8.9.22,
new NTCredentials(lliu, x, myhost, INXIGHT)
);

Where 'lliu' is a domain account


(2) Is the account you are using a domain account or a local one? This distinction is 
very important. If it is a local one, you should be using the host name instead of the 
domain name, even though the server may be a part of the INXIGHT domain

client.getState().setCredentials(
null,
10.8.9.22,
new NTCredentials(lliu, x, myhost, myhost)

Where 'lliu' is a local account on the 'myhost' host

Let me know the results

Oleg

-Original Message-
From: Lili Liu [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 04, 2004 20:26
To: Kalnichevski, Oleg
Subject: RE: IIS (NTLM) + proxy server (NTLM or basic) problem


Hi, Oleg:
I am focusing to get basic proxy + NTLM host work.
I downloaded the Httpclient package from the link below (May 4).

I still got the 401 error.
Here is the log.txt and my test program testProxy.java

One thing I thought maybe questionable is the first parameter of
setProxyCredentials is null in my case since the proxy does not belong to
any domain.

lili
Let me what you find.
Thanks a bunch!

-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 04, 2004 2:06 AM
To: Commons HttpClient Project
Subject: RE: IIS (NTLM) + proxy server (NTLM or basic) problem



Lili,
Truth to be told, NTLM proxy + NTLM host authentication has never been
properly tested, because none of us (HttpClient developers) has got access
to a Microsoft Proxy installation. I would not be surprised if it did not
work at all with HttpClient 2.0. I know for a fact that BASIC proxy + NTLM
host should work. I have been using Squid proxy to run the tests, though.


Anyways, could you please get hold of the latest HttpClient DEVELOPMENT
snapshot from the following location and see if it produces the same
results?


http://cvs.apache.org/builds/jakarta-commons/nightly/commons-httpclient/

It is much easier for me to troubleshoot the development version of
HttpClient because it's authentication code has become much saner.
Authentication code has undergone a complete rewrite for the 3.0 release and
_should_ be significantly more robust than that of HttpClient 2.0. Once the
problem is idenified and fixed, I'll port the changes to the stable
HttpClient branch

Please note that the development version (which is going to be the version
3.0 when released) is no longer 2.0 API compatible. You may have to make
some adjustments to your code.


Oleg

-Original Message-
From: Lili Liu [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 04, 2004 0:13
To: '[EMAIL PROTECTED]'
Subject: IIS (NTLM) + proxy server (NTLM or basic) problem


Hello,

I have tried all authentication combinations with IIS web server and
microsoft proxy server.
I have 401.1 error when both IIS are set up using NTLM and proxy server is
Basic or NTLM.

The proxy server set up code is as follows: (NTLM case)




client.getState().setAuthenticationPreemptive(false);
client.getHostConfiguration().setProxy(proxy IP
address, 80);
client.getState().setProxyCredentials(null, proxy
IP address,
new NTCredentials(proxy-server-username,
proxy-server-password, proxy-server-host, proxy-server-domain));

The web server connection is done as follows:



client.getState().setAuthenticationPreemptive(false);
client.getState().setCredentials(
null,
10.8.9.22,
new
NTCredentials(username, passwd, 10.8.9.22, INXIGHT);


Other combinations work well (IIS basic + proxy NTLM or proxy basic)
IIS NTLM without proxy server also works.

Log file is attached.

Any help is highly appreciated!

lili log.txt









***
The information in this email is confidential and may be legally privileged.
Access to this email by anyone other than the intended addressee is
unauthorized.  If you are not the intended recipient of this message, any
review, disclosure, copying, distribution, retention, or any action taken

RE: Yahoo login with Httpclient

[Kalnichevski, Oleg]

Frank,
You can start off by taking a look at the HttpClient cookie guide and redirect guide
http://jakarta.apache.org/commons/httpclient/cookies.html
http://jakarta.apache.org/commons/httpclient/redirects.html

If you happen to have any specific questions regarding HTTP cookies or redirect 
handling do not hesitate to ask

Sample code can be found here

http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/examples/?only_with_tag=HTTPCLIENT_2_0_BRANCH

Oleg

-Original Message-
From: Min (Frank) Ni [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 05, 2004 0:07
To: Commons HttpClient Project; [EMAIL PROTECTED]
Subject: RE: Yahoo login with Httpclient


I think I am just not familar with HttpClient enough to handle the cookies and 
redirects, would you be kind enough to show me some sample code ? Thanks.

Frank

-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 04, 2004 5:48 PM
To: Commons HttpClient Project
Subject: RE: Yahoo login with Httpclient


Frank,
I thought the problem had been resolved. What's wrong with taking
MrPostman's code as a starting point and implementing the same thing
using HttpClient?

Oleg

On Tue, 2004-05-04 at 23:41, Min (Frank) Ni wrote:
 Any luck in trying to get a page after logging into Yahoo with HttpClient ?

 Frank

 -Original Message-
 From: Michael Becke [mailto:[EMAIL PROTECTED]
 Sent: Thursday, April 29, 2004 12:35 AM
 To: Commons HttpClient Project
 Subject: Re: Yahoo login with Httpclient


 Well, I've tried a variety of things, but I cannot successfully login
 to yahoo.  Attached is the code that I've been using.  It includes two
 methods, one to simulate logging in from a browser with JavaScript
 turned off, and another to simulate with JS on.  Perhaps someone else
 can figure it out from here.

 Mike


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: IIS (NTLM) + proxy server (NTLM or basic) problem

[Kalnichevski, Oleg]

Lili,
Truth to be told, NTLM proxy + NTLM host authentication has never been properly 
tested, because none of us (HttpClient developers) has got access to a Microsoft Proxy 
installation. I would not be surprised if it did not work at all with HttpClient 2.0. 
I know for a fact that BASIC proxy + NTLM host should work. I have been using Squid 
proxy to run the tests, though.

Anyways, could you please get hold of the latest HttpClient DEVELOPMENT snapshot from 
the following location and see if it produces the same results?

http://cvs.apache.org/builds/jakarta-commons/nightly/commons-httpclient/

It is much easier for me to troubleshoot the development version of HttpClient because 
it's authentication code has become much saner. Authentication code has undergone a 
complete rewrite for the 3.0 release and _should_ be significantly more robust than 
that of HttpClient 2.0. Once the problem is idenified and fixed, I'll port the changes 
to the stable HttpClient branch

Please note that the development version (which is going to be the version 3.0 when 
released) is no longer 2.0 API compatible. You may have to make some adjustments to 
your code.

Oleg

-Original Message-
From: Lili Liu [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 04, 2004 0:13
To: '[EMAIL PROTECTED]'
Subject: IIS (NTLM) + proxy server (NTLM or basic) problem


Hello,

I have tried all authentication combinations with IIS web server and
microsoft proxy server.
I have 401.1 error when both IIS are set up using NTLM and proxy server is
Basic or NTLM.

The proxy server set up code is as follows: (NTLM case)


client.getState().setAuthenticationPreemptive(false);
client.getHostConfiguration().setProxy(proxy IP
address, 80);
client.getState().setProxyCredentials(null, proxy
IP address,
new NTCredentials(proxy-server-username,
proxy-server-password, proxy-server-host, proxy-server-domain));

The web server connection is done as follows:


client.getState().setAuthenticationPreemptive(false);
client.getState().setCredentials(
null,
10.8.9.22,
new
NTCredentials(username, passwd, 10.8.9.22, INXIGHT);


Other combinations work well (IIS basic + proxy NTLM or proxy basic)
IIS NTLM without proxy server also works.

Log file is attached.

Any help is highly appreciated!

lili log.txt







***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: NTLM authentication problem

[Kalnichevski, Oleg]

Hauke,
NTLM problems are notoriously difficult to troubleshoot. Usually it all boils down to 
extensive guesswork.
(1) is user name in the fully-qualified format: domain/account? If yes, use the 
account name only
(2) do you have any 'funny' characters in the password (like German umlauts, for 
instance)? If yes, try using an account with  plain US-ASCII password

Oleg

-Original Message-
From: Fuhrmann, Hauke [mailto:[EMAIL PROTECTED]
Sent: Monday, May 03, 2004 16:11
To: '[EMAIL PROTECTED]'
Subject: NTLM authentication problem


Hi there,

I hope you can help me with a little problem I got:

I have to download a file from a MS IIS webserver which uses NTLM
authentification. The only client I performed a successful download with is
MS IE. But I have to use a Java client, so I tried the jakarta commons
httpclient. I implemented a test class which sets the correct NTCredentials
and performs the request. The source looks somehow like this:

String url = http://host/index.html;;
NTCredentials creds =
 new NTCredentials(
 username,
 password,
 hostname,
 domain);
HttpClient client = new HttpClient();
HttpMethod method = new GetMethod(url);
client.getState().setCredentials(null, null, creds);

where 'username', 'password', 'hostname' and 'domain' are changed with the
correct values for the server.
After running
int statusCode = client.executeMethod(method);
I get the following logfile output:

---

[DEBUG] HttpClient - -Java version: 1.4.2
[DEBUG] HttpClient - -Java vendor: Sun Microsystems Inc.
[DEBUG] HttpClient - -Operating system name: Windows 2000
[DEBUG] HttpClient - -Operating system architecture: x86
[DEBUG] HttpClient - -Operating system version: 5.0
[DEBUG] HttpClient - -SUN 1.42: SUN (DSA key/parameter generation; DSA
signing; SHA-1, MD5 digests; SecureRandom; X.509 certificates; JKS
keystore; PKIX CertPathValidator; PKIX CertPathBuilder; LDAP, Collection
CertStores)
[DEBUG] HttpClient - -SunJSSE 1.42: Sun JSSE provider(implements RSA
Signatures, PKCS12, SunX509 key/trust factories, SSLv3, TLSv1)
[DEBUG] HttpClient - -SunRsaSign 1.42: SUN's provider for RSA signatures
[DEBUG] HttpClient - -SunJCE 1.42: SunJCE Provider (implements DES, Triple
DES, AES, Blowfish, PBE, Diffie-Hellman, HMAC-MD5, HMAC-SHA1)
[DEBUG] HttpClient - -SunJGSS 1.0: Sun (Kerberos v5)
[DEBUG] HttpConnection - -HttpConnection.setSoTimeout(0)
[DEBUG] HttpMethodBase - -Execute loop try 1
[DEBUG] wire - - GET /index.html HTTP/1.1[\r][\n]
[DEBUG] HttpMethodBase - -Adding Host request header
[DEBUG] wire - - User-Agent: Jakarta
Commons-HttpClient/2.0final[\r][\n]
[DEBUG] wire - - Host: host[\r][\n]
[DEBUG] wire - - [\r][\n]
[DEBUG] wire - - HTTP/1.1 401 Access Denied[\r][\n]
[DEBUG] wire - - Server: Microsoft-IIS/5.0[\r][\n]
[DEBUG] wire - - Date: Mon, 03 May 2004 12:47:03 GMT[\r][\n]
[DEBUG] wire - - WWW-Authenticate: Negotiate[\r][\n]
[DEBUG] wire - - WWW-Authenticate: NTLM[\r][\n]
[DEBUG] wire - - Connection: close[\r][\n]
[DEBUG] wire - - Content-Length: 24[\r][\n]
[DEBUG] wire - - Content-Type: text/html[\r][\n]
[DEBUG] HttpMethodBase - -Authorization required
[DEBUG] HttpAuthenticator - -Authenticating with the default authentication
realm at host
[DEBUG] HttpMethodBase - -HttpMethodBase.execute(): Server demanded
authentication credentials, will try again.
[DEBUG] wire - - Error: Access is Denied.
[DEBUG] HttpMethodBase - -Should close connection in response to
Connection: close

[DEBUG] HttpMethodBase - -Execute loop try 2
[DEBUG] HttpMethodBase - -Opening the connection.
[DEBUG] wire - - GET /index.html HTTP/1.1[\r][\n]
[DEBUG] HttpMethodBase - -Request to add Host header ignored: header
already added
[DEBUG] wire - - User-Agent: Jakarta
Commons-HttpClient/2.0final[\r][\n]
[DEBUG] wire - - Host: host[\r][\n]
[DEBUG] wire - - Authorization: NTLM
TlRMTVNTUAABBlIAABgAGAAoCAAIACBEMDE1Nzc4MkFGSVMuUk9DS1dFTExDT0x
MSU5TLkNPTQ==[\r][\n]
[DEBUG] wire - - [\r][\n]
[DEBUG] wire - - HTTP/1.1 401 Access Denied[\r][\n]
[DEBUG] wire - - Server: Microsoft-IIS/5.0[\r][\n]
[DEBUG] wire - - Date: Mon, 03 May 2004 12:47:03 GMT[\r][\n]
[DEBUG] wire - - WWW-Authenticate: NTLM
TlRMTVNTUAACBAAEADAGAoEAfy2cSecyuJ8AAI4AjgA0QUZJUwIACAB
BAEYASQBTAAEACABBAE4AUwBVAAQAMABhAGYAaQBzAC4AcgBvAGMAawB3AGUAbABsAGMAbwBsAG
wAaQBuAHMALgBjAG8AbQADADoAYQBuAHMAdQAuAGEAZgBpAHMALgByAG8AYwBrAHcAZQBsAGwAY
wBvAGwAbABpAG4AcwAuAGMAbwBtAAA=[\r][\n]
[DEBUG] wire - - Content-Length: 24[\r][\n]
[DEBUG] wire - - Content-Type: text/html[\r][\n]
[DEBUG] HttpMethodBase - -Authorization required
[DEBUG] HttpAuthenticator - -Authenticating with the default authentication
realm at host
[DEBUG] HttpMethodBase - -HttpMethodBase.execute(): Server demanded
authentication credentials, will try again.
[DEBUG] wire - - Error: Access is Denied.
[DEBUG] HttpMethodBase - -Resorting to protocol version default close
connection policy
[DEBUG] HttpMethodBase - -Should NOT close connection, using HTTP/1.1.
[DEBUG] 

Project team page (was RE: Release notes update. Please review)

[Kalnichevski, Oleg]

 On a related note, Oleg, are you also working on updating the list of 
 contributors?  If not, I will take a look at it.

Mike,

I found this to be quite a touchy issue. I have been thinking whether there's an 
acceptable way to inject a little more structure into the standard Maven generated 
contributors page. In particular I'd like to be able to mark inactive contributors as, 
well, inactive ones and retired committers as retired ones to give a little more 
prominence to the active ones. I was unable so far to come up with any idea how this 
could be accomplished without taking a risk of upsetting some folks and provoking some 
tensions on the mailing list. I have been thinking about some sort 'HttpClient 
history' page which would contain chronological account of important events including 
credits for notable personal contributions, leaving the project team to reflect 
_current_ _active_ participation in the project. However, for the Lord's sake no way 
do I want to provoke no trouble between HttpClient contributors and committers thus 
causing more harm than good with my innovation. In my thoughts I was gradually 
gravitating towards not messing around the 'project team' page and simply appending 
new entries to the existing list when you caught me with your question ;-)

If there are no better ideas how to deal with the issue, I'll add the new entrants to 
the existing list and get it over with

Oleg


-Original Message-
From: Michael Becke [mailto:[EMAIL PROTECTED]
Sent: Monday, May 03, 2004 2:41
To: Commons HttpClient Project
Subject: Re: Release notes update. Please review


Wow, has it been a year already?  It seems hard to believe.

Oleg, nice work on compiling the list of changes.  This is no small 
task.

On a related note, Oleg, are you also working on updating the list of 
contributors?  If not, I will take a look at it.

Thanks,

Mike

On May 2, 2004, at 6:08 PM, Oleg Kalnichevski wrote:

 Folks,
 I just updated the release notes doc to include personal contributions
 made to HttpClient CVS HEAD since 2.0 was branched out (approx a year
 from now)

 http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/
 release_notes.txt?rev=1.19view=markup

 If you have contributed code or design ideas during that period, please
 review the release notes to make sure your contribution is mentioned.

 If certain contributions are not mentioned, it does not necessarily 
 mean
 that they do not deserve mentioning. Going through several hundreds of
 commit messages is tedious, not great fun, and very prone to mistakes. 
 I
 may well have overlooked quite a few things

 It is important that we keep this document up to date, as one day is 
 may
 become the only (easily accessible) vehicle of communicating individual
 contributions. @author tags may have to be removed, if so decides the
 Jakarta PMC

 So, no need to be shy. If there's anything omitted, please do let me
 know

 Oleg


 -
 To unsubscribe, e-mail: 
 [EMAIL PROTECTED]
 For additional commands, e-mail: 
 [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Yahoo login with Httpclient

[Kalnichevski, Oleg]

Frank,
I just what to add one thing to what Roland has said: basically the authentication 
with the developer.java.sun.com succeeded. You got the session cookie back. HttpClient 
was simply unable to process the post-logon redirect, but this limitation is not 
difficult to work around (see the redirect guide). I am sure it should not be that 
difficult to form-based login with get my.yahoo.com working. Give it another try

Oleg


-Original Message-
From: Min (Frank) Ni [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 28, 2004 16:28
To: Commons HttpClient Project; [EMAIL PROTECTED]
Subject: RE: Yahoo login with Httpclient


Hi Oleg:

Thanks for your reply. Two days ago I tried the FormLoginDemo, but after I saw your 
e-mail I tried again and got the following response, with my Sun Developer Id and 
password :

===

Login form get: HTTP/1.1 200 OK
Initial set of cookies:
None
Apr 28, 2004 10:05:24 AM org.apache.commons.httpclient.HttpMethodBase 
processRedirectResponse
INFO: Redirect requested but followRedirects is disabled
Login form post: HTTP/1.1 302 Moved Temporarily
Logon cookies:
- JDC=5719750140229660595
- JSESSIONID=developer.java.sun.com-e7b9%253A408fba23%253Af8cfb4dd3166b6ce
- SessionCredentials=5213651892774654901
Redirect target: http://developer.java.sun.com/index.html
Apr 28, 2004 10:05:24 AM org.apache.commons.httpclient.HttpMethodBase 
checkValidRedirect
WARNING: Error getting URI host
org.apache.commons.httpclient.HttpException: Redirect from host developer.java.sun.com 
to java.sun.com is not supported
at 
org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect(HttpMethodBase.java:1243)
at 
org.apache.commons.httpclient.HttpMethodBase.processRedirectResponse(HttpMethodBase.java:1191)
at 
org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded(HttpMethodBase.java:977)
at 
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1095)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:675)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:529)
at FormLoginDemo.main(FormLoginDemo.java:124)
Apr 28, 2004 10:05:24 AM org.apache.commons.httpclient.HttpMethodBase 
processRedirectResponse
WARNING: Invalid Redirect URI from: http://developer.java.sun.com:80/index.html to: 
http://java.sun.com/
Redirect: HTTP/1.1 302 Moved Temporarily

===

The probelm with Yahoo login is even harder to understand, it seems Yahoo redirects 
several times, and it requires cookies, I tried the following lines, but it won't work 
:

===
System.getProperties().put(java.protocol.handler.pkgs, HTTPClient);
   
String url=https://login.yahoo.com/config/login;;
//String url=http://f1.pg.briefcase.yahoo.com/;;
HttpClient client = new HttpClient();
HttpMethod method = new GetMethod(url);

try
{
//  URL url=new URL(https://login.yahoo.com/config/login;);   
/*  String Msg_Out=.fUpdate=1\n+
 .tries=1\n+
 .done=http://f1.pg.briefcase.yahoo.com/\n+
 .src=bc\n+
 .intl=us\n+
 login=javamr\n+
 passwd=javatest\n+
 submit=Login;

  String Msg_Out=.fUpdate=1+
 .tries=1+
 .done=http://f1.pg.briefcase.yahoo.com/+
 .src=bc+
 .intl=us+
 login=javamr+
 passwd=javatest+
 submit=Login;

//  WriteFile Write_File=new WriteFile(url,Msg_Out);
//  taText.append(Write_File.Text_In.toString());
//  NM_Lib.Display_HTML_In_Browser(Write_File.Text_In.toString());

//  method.setQueryString(Msg_Out);
*/  
  NameValuePair N_V_P[]= { new NameValuePair(.fUpdate,1),
   new NameValuePair(.tries,1),
   new 
NameValuePair(.done,http://f1.pg.briefcase.yahoo.com/;),
   new NameValuePair(.src,bc),
   new NameValuePair(.intl,us),
   new NameValuePair(login,javamr),
   new NameValuePair(passwd,javatest),
   new NameValuePair(submit,Login)
 };

  method.setQueryString(N_V_P);
  client.executeMethod(method);
   
}
catch (Exception e) { System.out.println(e.toString()); }
  
String responseBody = method.getResponseBodyAsString();
method.releaseConnection();
//NM_Lib.Display_HTML_In_Browser(responseBody);
  }

RE: Release 2.0 Final - PGP MD5

[Kalnichevski, Oleg]

Chris,

We already have a bug report pending for this:

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27026

My (unofficial) plan was to take care of it for the next releases: 3.0-alpha1 
(expected within a month) and 2.0.1 (has not been discussed yet, but certainly 
imminent). If it is important we can look into possibility of recreating the 
distributions. However, I'd rather have this time spent on getting 3.0-alpha1 out 
faster. Can this wait until next stable release?

Oleg

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 28, 2004 17:48
To: [EMAIL PROTECTED]
Subject: Release 2.0 Final - PGP  MD5


When will HttpClient 2.0 Final be signed -- PGP signatures  MD5 checksum
available?  Currently, it is listed as unsigned on the binary download
page.  Thanks!

Chris




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Problems using SSL from inside JBoss (jsse problem?)

[Kalnichevski, Oleg]

Fredrik,

This problem is clearly not HttpClient related, hence you have not been getting a lot 
of responses. HttpClient simply expects JSSE to be there and be properly configured in 
order for the HTTPS support to be functional. Please take a look at the HttpClient SSL 
guide paying special attention to the troubleshooting section

http://jakarta.apache.org/commons/httpclient/sslguide.html

Hope this helps a little

Oleg


-Original Message-
From: Fredrik Bonde [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 21, 2004 13:18
To: '[EMAIL PROTECTED]'
Subject: Problems using SSL from inside JBoss (jsse problem?)


Hi all, I got a questing regarding using HttpClient from an MDB inside
Jboss.
Normal http connections work fine, but whenever I try to connect to a host
using https I get a SocketException, claiming SSL is not available:

12:13:39,338 INFO  [STDOUT] 2004-04-21 12:13:39,322 ERROR
(HttpClientWrapper.java:120) Unable to connect to 'https://mail.yahoo.com'
java.net.SocketException: SSL implementation not available
at
javax.net.ssl.DefaultSSLSocketFactory.createSocket([DashoPro-V1.2-120198])
at
org.apache.commons.httpclient.protocol.SSLProtocolSocketFactory.createSocket
(SSLProtocolSocketFactory.java:112)
at
org.apache.commons.httpclient.HttpConnection$1.doit(HttpConnection.java:691)
at
org.apache.commons.httpclient.HttpConnection$SocketTask.run(HttpConnection.j
ava:1299)
at java.lang.Thread.run(Thread.java:534)
12:13:39,322 ERROR [HttpClientWrapper] Unable to connect to
'https://mail.yahoo.com'
java.net.SocketException: SSL implementation not available
at
javax.net.ssl.DefaultSSLSocketFactory.createSocket([DashoPro-V1.2-120198])
at
org.apache.commons.httpclient.protocol.SSLProtocolSocketFactory.createSocket
(SSLProtocolSocketFactory.java:112)
at
org.apache.commons.httpclient.HttpConnection$1.doit(HttpConnection.java:691)
at
org.apache.commons.httpclient.HttpConnection$SocketTask.run(HttpConnection.j
ava:1299)
at java.lang.Thread.run(Thread.java:534)

The code works fine outside Jboss so I suppose there something I need to do
in order to enable jsse for Jboss. The problem is that I do not have a clue
*how* to set it up! If anyone could help me it would be greatly appreciated.



I'm using Java 1.4_02, HttpClient 2.0-final and Jboss 3.2.3. I have also
tried to set the system property java.protocol.handler.pkgs to
com.sun.net.ssl.internal.www.protocol using:
String sRes =
System.setProperty(java.protocol.handler.pkgs,com.sun.net.ssl.internal.ww
w.protocol);

also I try to add a provider with:
Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider()); 

code looks like this:
  HttpClient httpClient = new HttpClient();
httpClient.setConnectionTimeout(connectTimeout);
httpClient.setTimeout(readTimeout);

  HttpMethod method = null;

//debug
System.setProperty(org.apache.commons.logging.Log,
org.apache.commons.logging.impl.SimpleLog);

System.setProperty(org.apache.commons.logging.simplelog.showdatetime,
true);

System.setProperty(org.apache.commons.logging.simplelog.log.httpclient.wire
, debug);

System.setProperty(org.apache.commons.logging.simplelog.log.org.apache.comm
ons.httpclient, debug);


String sRes =
System.setProperty(java.protocol.handler.pkgs,com.sun.net.ssl.internal.ww
w.protocol);
int ret = Security.addProvider(new
com.sun.net.ssl.internal.ssl.Provider()); 


method = new GetMethod(url.toExternalForm());
method.setFollowRedirects(true);

//execute the method
try{
httpClient.executeMethod(method);  // here exception is thrown
String res =  method.getResponseBodyAsString();
method.releaseConnection();
return res;

} catch (HttpException e) {
_log.error(Http error connecting to ' + url + ', e);
throw new HttpClientException(e.getMessage());

} catch (IOException e){
_log.error(Unable to connect to ' + url + ', e);
throw new HttpClientException(e.getMessage());
}

Kind regards,

Fredrik Bonde ~ Java Developer



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, 

RE: customizing debugging levels per httpclient instance

[Kalnichevski, Oleg]

Jorrit,

HttpClient relies on commons-logging toolkit to do all its logging. The 
commons-logging itself is merely an abstraction layer intended to provide a uniform 
interface to different logging toolkits. If there is a toolkit capable of assigning 
different appenders on per thread basis, then HttpClient can be configured to take 
advantage of it. To my best knowledge Log4j cannot assign individual appenders to 
different threads within the same application (within the same class loader context 
rather). You may consider evaluating a different logging toolkit that provides such a 
feature, or file a feature request with the Log4j project.

Oleg


-Original Message-
From: Jorrit Kronjee [mailto:[EMAIL PROTECTED]
Sent: Monday, April 26, 2004 13:19
To: [EMAIL PROTECTED]
Subject: customizing debugging levels per httpclient instance


Hello,

I have an application consisting of two threads. Both threads have an
own instance of httpclient and use it for different things. I would like
to see the wire of one of the threads, but suppress the other. I use
log4j. log4j can set the debugging level (trace or not) based on
package/class names. I was wondering if it's possible to set the class
name for http client, so i can customize my debugging per thread. Or
perhaps I'm not understanding it correctly.

If this is not possible, I would like to make this a feature request.

Thanks in advance,


Jorrit Kronjee

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Problem with Binary release, 2-15-2004 Zip

[Kalnichevski, Oleg]

Brit,

There are currently two HttpClient branches: CVS HEAD (development, no longer 
compatible with the 2.0 API) and the 2.0 compatible branch (stable). I suspect you 
have gotten the PostXML code off CVS HEAD, which does not compile against 2.0 final. 
Please try examples shipped with HttpClient 2.0 source distribution.

Oleg

-Original Message-
From: Pair, Brit [mailto:[EMAIL PROTECTED]
Sent: Monday, April 26, 2004 17:14
To: [EMAIL PROTECTED]
Subject: Problem with Binary release, 2-15-2004 Zip


I just downloaded the latest Binary Release Build, 2/15/2004 Zip.

When I tried to use the tutorial code and PostXML code I had a bunch of errors.

It appears that HttpMethodBase does not have a relesaeConnection method and PostMethod 
extends GetMethod directly rather than EntityEnclosingMethod.

I then downloaded the source code and it looks correct.

Maybe the binary is an earlier version?

thanks,

Brit

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Problem with Binary release, 2-15-2004 Zip

[Kalnichevski, Oleg]

Brit,
I just downloaded a fresh copy of commons-httpclient-2.0-src.zip and managed to 
compile everything the complete source including the examples after having added 
commons-logging.jar and junit.jar to the project classpath. Then I compiled the 
examples only using the jar shipped with the commons-httpclient-2.0.zip. As far as I 
am concerned everything compiles just fine

Please download a fresh copy of HttpCliet from 
http://jakarta.apache.org/commons/httpclient/downloads.html and try again

Please also double-check your classpath and make sure you do not have an older version 
of HttpClient (shipped with Slides, for instance) on it

HTH

Oleg

-Original Message-
From: Pair, Brit [mailto:[EMAIL PROTECTED]
Sent: Monday, April 26, 2004 19:48
To: Commons HttpClient Project
Subject: RE: Problem with Binary release, 2-15-2004 Zip


Not sure I understand.

I downloaded the 2.0 Binary Release Build and the 2.0 Source Release Build and they 
have different APIs. I would expect that compiling the source would produce something 
compatible with the downloaded binary. Something is either not marked clearly or the 
Binary download is not the 2.0 Release Build.

If you want the online tutorial and examples to work you have to use the 2.0 Release 
Source Build because the 2.0 Release Binary Build is missing methods.

If I am missing something here I apologize.

Brit


-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: Monday, April 26, 2004 11:43 AM
To: Commons HttpClient Project
Subject: RE: Problem with Binary release, 2-15-2004 Zip



Brit,

There are currently two HttpClient branches: CVS HEAD (development, no longer 
compatible with the 2.0 API) and the 2.0 compatible branch (stable). I suspect you 
have gotten the PostXML code off CVS HEAD, which does not compile against 2.0 final. 
Please try examples shipped with HttpClient 2.0 source distribution.


Oleg

-Original Message-
From: Pair, Brit [mailto:[EMAIL PROTECTED]
Sent: Monday, April 26, 2004 17:14
To: [EMAIL PROTECTED]
Subject: Problem with Binary release, 2-15-2004 Zip


I just downloaded the latest Binary Release Build, 2/15/2004 Zip.

When I tried to use the tutorial code and PostXML code I had a bunch of errors.

It appears that HttpMethodBase does not have a relesaeConnection method and PostMethod 
extends GetMethod directly rather than EntityEnclosingMethod.

I then downloaded the source code and it looks correct.

Maybe the binary is an earlier version?

thanks,

Brit

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Broken link on website

[Kalnichevski, Oleg]

Mike,
I am planning to tackle this one in the coming days
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26499

So, I'll be messing around the maven files, but that should not affect the site 
generation. Just to avoid unnecessary overlap

Oleg


-Original Message-
From: Michael Becke [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 21, 2004 14:38
To: Commons HttpClient Project
Subject: Re: Broken link on website


Yes, I merged(manually) in the changes from project.xml and 
project.properties.  I think I was able to get everything building 
correctly.  Please take a look at the site and let me know if I've 
missed anything.

Mike


On Apr 21, 2004, at 12:28 AM, Mark R. Diggory wrote:

 You should probibly just need to merge the project.xml and 
 project.properties from the Head into the 2.0 branch (if you can merge 
 in that direction?). or just copy thier contents. those files are the 
 only ones adjusted to alter the look and feel. If you've been working 
 with branches already, someone in the group must be familiar with 
 merging (I'm not).

 -Mark

 Michael Becke wrote:

 The site has been updated with the new commons LF.  I made a quick  
 change to the HttpClient logo so that it's visible, but I assume we 
 may  want to do something more permanent.

 Mike

 On Apr 20, 2004, at 8:22 AM, Kalnichevski, Oleg wrote:


 Mark,
 There is a few little problems generating HttpClient 2.0 site using  
 maven rc2:
 (1) Currently we generate HttpClient site off the 2.0 branch rather  
 CVS HEAD. The same changes made to the project.xml in CVS HEAD need 
 to  be made in the 2.0 branch. I'll take care of that unless someone 
 beats  me to it

 http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/ 
 project.xml?r1=1.43r2=1.44diff_format=h

 (2) New while background renders HttpClient logo unreadable (white 
 on  white). Is there anything that can be done about it?

 (3) The link to the Commons Logging site in the HttpClient redirect  
 guide still needs to be fixed. I'll take care of that (again, unless 
  someone beats me to it)

 Otherwise +1 from me

 Oleg

 PS:

 None of the HttpClient regulars seems proficient enough with maven 
 to  be able to tackle the following request:

 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26499

 Any pointers as to how this problem can fixed?



 -Original Message-
 From: Mark R. Diggory [mailto:[EMAIL PROTECTED]
 Sent: Monday, April 19, 2004 17:08
 To: Commons HttpClient Project
 Subject: Re: Broken link on website


 Roland Weber wrote:

 Hi guys,

 I just found a broken link in the Logging Guide.
 The Commons Logging home page has moved from

 http://jakarta.apache.org/commons/logging.html

 to
 http://jakarta.apache.org/commons/logging/

 cheers,
  Roland



 I think I'm just going to go ahead and move into place the genreated
 maven site like we voted on, I got everrun at work last week. The 
 links
 from the maven generated site point to the correct location.

 -Mark


 -
 To unsubscribe, e-mail:  
 [EMAIL PROTECTED]
 For additional commands, e-mail:  
 [EMAIL PROTECTED]


 *
 ** 
 The information in this email is confidential and may be legally  
 privileged.  Access to this email by anyone other than the intended  
 addressee is unauthorized.  If you are not the intended recipient of 
  this message, any review, disclosure, copying, distribution,  
 retention, or any action taken or omitted to be taken in reliance on 
  it is prohibited and may be unlawful.  If you are not the intended  
 recipient, please reply to or forward a copy of this message to the  
 sender and delete the message, any attachments, and any copies 
 thereof  from your system.
 *
 ** 

 -
 To unsubscribe, e-mail:  
 [EMAIL PROTECTED]
 For additional commands, e-mail:  
 [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: 
 [EMAIL PROTECTED]
 For additional commands, e-mail: 
 [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: 
 [EMAIL PROTECTED]
 For additional commands, e-mail: 
 [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying

RE: Broken link on website

[Kalnichevski, Oleg]

Mark,
There is a few little problems generating HttpClient 2.0 site using maven rc2:
(1) Currently we generate HttpClient site off the 2.0 branch rather CVS HEAD. The same 
changes made to the project.xml in CVS HEAD need to be made in the 2.0 branch. I'll 
take care of that unless someone beats me to it

http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/project.xml?r1=1.43r2=1.44diff_format=h

(2) New while background renders HttpClient logo unreadable (white on white). Is there 
anything that can be done about it?

(3) The link to the Commons Logging site in the HttpClient redirect guide still needs 
to be fixed. I'll take care of that (again, unless someone beats me to it)

Otherwise +1 from me

Oleg

PS:

None of the HttpClient regulars seems proficient enough with maven to be able to 
tackle the following request:

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26499

Any pointers as to how this problem can fixed?



-Original Message-
From: Mark R. Diggory [mailto:[EMAIL PROTECTED]
Sent: Monday, April 19, 2004 17:08
To: Commons HttpClient Project
Subject: Re: Broken link on website


Roland Weber wrote:

Hi guys,

I just found a broken link in the Logging Guide.
The Commons Logging home page has moved from

http://jakarta.apache.org/commons/logging.html

to
http://jakarta.apache.org/commons/logging/

cheers,
  Roland

 

I think I'm just going to go ahead and move into place the genreated
maven site like we voted on, I got everrun at work last week. The links
from the maven generated site point to the correct location.

-Mark


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Broken link on website

[Kalnichevski, Oleg]

Mark,

 What your guys timeframe for migrating up to Jakarta? I think this will
 dictate how invloved we get with the branching in your cvs tree.

We have not even started debating on this issue.

I personally would VERY STRONGLY favour releasing 3.0 out of Commons first and only 
then gradually migrating to the Jakarta level as HttpClient undergoes a long complete 
redesign. Being realistic, 3.0 development should take 8 to 12 months, possibly more. 
We definitely want to have some presence at the Jakarta level pretty much immediately. 
Most of the links, though, would still point at the Commons HttpClient resources


 I can't come up with one beyond hardcoding Windows EOL's. I seldom use
 notepad and always reassign the txt extension over to Wordpad on
 Windows boxes. Though, this doesn't solve this problem really.

All it takes is a simple Ant script. The trouble is I have no idea how to make Maven 
execute an Ant target as a part of release process. This is where I'd greatly 
appreciate a bit of help

Oleg


-Original Message-
From: Mark R. Diggory [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 20, 2004 16:53
To: Kalnichevski, Oleg
Cc: Commons HttpClient Project
Subject: Re: Broken link on website



Kalnichevski, Oleg wrote:

Mark,
There is a few little problems generating HttpClient 2.0 site using maven rc2:
(1) Currently we generate HttpClient site off the 2.0 branch rather CVS HEAD. The 
same changes made to the project.xml in CVS HEAD need to be made in the 2.0 branch. 
I'll take care of that unless someone beats me to it

http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/project.xml?r1=1.43r2=1.44diff_format=h

 

What your guys timeframe for migrating up to Jakarta? I think this will
dictate how invloved we get with the branching in your cvs tree.

(2) New while background renders HttpClient logo unreadable (white on white). Is 
there anything that can be done about it?

 

Again, with migration to Jakrta, you might want to generate some new Logo's

(3) The link to the Commons Logging site in the HttpClient redirect guide still needs 
to be fixed. I'll take care of that (again, unless someone beats me to it)

Otherwise +1 from me

Oleg
 

I went to regenerate the site using rc2 and failed, I generated and put
inplace the new mavenized site. the link should work in this location.

PS:

None of the HttpClient regulars seems proficient enough with maven to be able to 
tackle the following request:

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26499

Any pointers as to how this problem can fixed?

 

I can't come up with one beyond hardcoding Windows EOL's. I seldom use
notepad and always reassign the txt extension over to Wordpad on
Windows boxes. Though, this doesn't solve this problem really.

-Original Message-
From: Mark R. Diggory [mailto:[EMAIL PROTECTED]
Sent: Monday, April 19, 2004 17:08
To: Commons HttpClient Project
Subject: Re: Broken link on website


Roland Weber wrote:

 

Hi guys,

I just found a broken link in the Logging Guide.
The Commons Logging home page has moved from

http://jakarta.apache.org/commons/logging.html

to
http://jakarta.apache.org/commons/logging/

cheers,
 Roland



   

I think I'm just going to go ahead and move into place the genreated
maven site like we voted on, I got everrun at work last week. The links
from the maven generated site point to the correct location.

-Mark


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you 
are not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***
 



***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from

RE: Broken link on website

[Kalnichevski, Oleg]

Thanks, Mark. You rock

Oleg

-Original Message-
From: Mark R. Diggory [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 20, 2004 18:22
To: Kalnichevski, Oleg
Cc: Apache Commons HttpClient (E-mail)
Subject: Re: Broken link on website


Ant can be executed within Maven failry easily. If you have the ant
target, you can usually just copy its contents into the maven.xml file
and have it called prior to the goal being executed. Something like:

 preGoal name=dist
   !-- place your ant tasks here --
  /preGoal

for instance, here is the content of the httpclient/maven.xml

?xml version=1.0?
!-- Author: Jeff Dever --

project

  !--
Builds the HttpClient distribution.  Ensures that the site docs are
included
in the dist.
  --
  goal name=httpclient:dist prereqs=site:generate, dist/

  postGoal name=dist:prepare-bin-filesystem

echo[HttpClient] dist:prepare-bin-filesystem postGoal/echo

copy todir=${maven.dist.bin.assembly.dir}/docs
  fileset dir=./docs
include name=*.txt/
include name=*.html/
  /fileset
  fileset dir=target/docs
include name=**/*/
  /fileset
/copy
  
  /postGoal

  postGoal name=dist:prepare-src-filesystem

echo[HttpClient] dist:prepare-src-filesystem postGoal/echo

copy todir=${maven.dist.src.assembly.dir}
  fileset dir=.
include name=build.properties.sample/
  /fileset
/copy

copy todir=${maven.dist.src.assembly.dir}/docs
  fileset dir=./docs
include name=*.txt/
include name=*.html/
  /fileset
  fileset dir=target/docs
include name=**/*/
  /fileset
/copy
  
  /postGoal

/project

Kalnichevski, Oleg wrote:

Mark,

 

What your guys timeframe for migrating up to Jakarta? I think this will
dictate how invloved we get with the branching in your cvs tree.
   


We have not even started debating on this issue.

I personally would VERY STRONGLY favour releasing 3.0 out of Commons first and only 
then gradually migrating to the Jakarta level as HttpClient undergoes a long complete 
redesign. Being realistic, 3.0 development should take 8 to 12 months, possibly more. 
We definitely want to have some presence at the Jakarta level pretty much 
immediately. Most of the links, though, would still point at the Commons HttpClient 
resources


 

I can't come up with one beyond hardcoding Windows EOL's. I seldom use
notepad and always reassign the txt extension over to Wordpad on
Windows boxes. Though, this doesn't solve this problem really.
   


All it takes is a simple Ant script. The trouble is I have no idea how to make Maven 
execute an Ant target as a part of release process. This is where I'd greatly 
appreciate a bit of help

Oleg


-Original Message-
From: Mark R. Diggory [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 20, 2004 16:53
To: Kalnichevski, Oleg
Cc: Commons HttpClient Project
Subject: Re: Broken link on website



Kalnichevski, Oleg wrote:

 

Mark,
There is a few little problems generating HttpClient 2.0 site using maven rc2:
(1) Currently we generate HttpClient site off the 2.0 branch rather CVS HEAD. The 
same changes made to the project.xml in CVS HEAD need to be made in the 2.0 branch. 
I'll take care of that unless someone beats me to it

http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/project.xml?r1=1.43r2=1.44diff_format=h



   

What your guys timeframe for migrating up to Jakarta? I think this will
dictate how invloved we get with the branching in your cvs tree.

 

(2) New while background renders HttpClient logo unreadable (white on white). Is 
there anything that can be done about it?



   

Again, with migration to Jakrta, you might want to generate some new Logo's

 

(3) The link to the Commons Logging site in the HttpClient redirect guide still 
needs to be fixed. I'll take care of that (again, unless someone beats me to it)

Otherwise +1 from me

Oleg


   

I went to regenerate the site using rc2 and failed, I generated and put
inplace the new mavenized site. the link should work in this location.

 

PS:

None of the HttpClient regulars seems proficient enough with maven to be able to 
tackle the following request:

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26499

Any pointers as to how this problem can fixed?



   

I can't come up with one beyond hardcoding Windows EOL's. I seldom use
notepad and always reassign the txt extension over to Wordpad on
Windows boxes. Though, this doesn't solve this problem really.

 

-Original Message-
From: Mark R. Diggory [mailto:[EMAIL PROTECTED]
Sent: Monday, April 19, 2004 17:08
To: Commons HttpClient Project
Subject: Re: Broken link on website


Roland Weber wrote:



   

Hi guys,

I just found a broken link in the Logging Guide.
The Commons Logging home page has moved from

http://jakarta.apache.org/commons/logging.html

to
http://jakarta.apache.org/commons/logging/

cheers,
Roland



 

 

I think I'm just going to go ahead and move

RE: Socket redirect

[Kalnichevski, Oleg]

Thorsten,

 2004.04.20 18:30:54,378 [http8090-Processor4] WARN  
 org.apache.commons.httpclient.HttpConnection -
 The host  www.andaluciajunta.es:80 (or proxy null:-1) did not accept the connection 
 within timeout
 of 15000 milliseconds


Something tells me that this looks suspiciously like a connection timeout ;-) Have you 
tried using a value greater than 15sec or disabling connect timeout altogether?

Oleg


-Original Message-
From: Thorsten Scherler
[mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 20, 2004 18:47
To: Commons HttpClient Project
Subject: Socket redirect


Hello group,

I have written a sonar for web services. One part of that application
is the httpClient.
It is quite simple: I will do a checkup whether a web server is online
or not. I am using the http-response code for that. Everything works
like it should.

Now my problem: In my company there are some redirects to certain
server. e.g.  my boss is monitoring http://www.andaluciajunta.es. That
page will be redirected to http://andaluciajunta.es. Than I will get the
following error:

2004.04.20 18:30:46,098 [Thread-704] ERROR sonda.sonar.HttpClient - Failed to download 
file.
Thorsten
at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:716)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:661)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:529)
   ...

2004.04.20 18:30:54,378 [http8090-Processor4] WARN  
org.apache.commons.httpclient.HttpConnection - The host www.andaluciajunta.es:80 (or 
proxy null:-1) did not accept the connection within timeout of 15000 milliseconds

2004.04.20 18:30:54,378 [http8090-Processor4] ERROR sonda.sonar.HttpClient - Failed to 
download file.
org.apache.commons.httpclient.HttpConnection$ConnectionTimeoutException
at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:716)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:661)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:529)
at sonda.sonar.HttpClient.getHttp(HttpClient.java:66)
...

I know that was before in this list, but can't google a workaround to that problem!

Do have anybody an idea how can I solve that?

Any help very appreciated!

king regards
Thorsten


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Project team page update

[Kalnichevski, Oleg]

Christian,
My apologies for having forgotten about you. Your SimpleHttpServer framework is the 
coolest contribution of late, IMHO. My intention to eventually phase out all test 
cases reliant on 'Webapp' and 'SimpleHttpConnection' stuff and have them replaced with 
the test cases based on SimpleHttpServer framework.

Many thanks for it, once again.

Oleg

-Original Message-
From: Christian Kohlschütter [mailto:[EMAIL PROTECTED]
Sent: Monday, April 19, 2004 9:54
To: [EMAIL PROTECTED]
Cc: Oleg Kalnichevski
Subject: Re: Project team page update


On Thursday 15 April 2004 23:49, Oleg Kalnichevski wrote:
 Folks,
 I would like to bring the project team page
 http://jakarta.apache.org/commons/httpclient/team-list.html up to date
 and add recent contributors to the list:

 Roland Weber
 Sam Berlin
 Mohammad Rezaei

 Have I forgotten anyone? Please speak out. No need to be shy

 Oleg

If there aren't any objections, I would like to be added to this list as a
contributor as well.

I have contributed the SimpleHttpServer framework as well as some tweaks to
HttpMethodBase.

Thanks in advance,

Christian Kohlschütter ([EMAIL PROTECTED])

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: HttpClient for Https gives Unrecognized SSL message..

[Kalnichevski, Oleg]

Raj,

Please note that HttpClient simply makes use of JSSE and does not attempt to provide 
any sort of transport security by itself. As far as HttpClient is concerned SSL is 
just a transport layer which is supposed to be completely transparent to HttpClient. 
I'll do my best to help you out, but please note this problem is VERY, VERY unlikely 
to be caused by HttpClient in the first place. First and foremost you need to ensure 
that JSSE is properly configured and is capable of communication with the target 
server.

Did you try the SSL test described in the troubleshooting section of the SSL guide 
http://jakarta.apache.org/commons/httpclient/sslguide.html? If not, please do so and 
let us know the result.

Oleg

-Original Message-
From: Raj, Bhalla [mailto:[EMAIL PROTECTED]
Sent: Monday, April 19, 2004 16:25
To: Commons HttpClient Project
Subject: RE: HttpClient for Https gives Unrecognized SSL message..


Hi Oleg,

Thanks for your response.

I am using from browser to connect to test this.
https://URL?method=book_hotelxml

and i get certificate to accept from browser and after accepting the
certificate
 i get proper XML response from server.

But when i do this from java client i get following error as mentioned

Caused by: javax.net.ssl.SSLException: Unrecognized SSL message, plaintext
connection?
at com.sun.net.ssl.internal.ssl.InputRecord.b(DashoA6275)
at com.sun.net.ssl.internal.ssl.InputRecord.read(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)

So i assume SSL is properly installed on server.

Pleas help.Another way to debug this.

Thanks
Raj

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, April 19, 2004 3:50 PM
To: Commons HttpClient Project
Subject: RE: HttpClient for Https gives Unrecognized SSL message..


Raj,
Are you sure that SSL is configured on the server side? Unrecognized SSL
message, plaintext connection? exception is usually thrown when an attempt
is made to connect SSLSocket to a plain HTTP port

Oleg


-- Original Message --
Reply-To: Commons HttpClient Project
[EMAIL PROTECTED]
From: Raj, Bhalla [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: HttpClient for Https gives Unrecognized SSL message..
Date: Mon, 19 Apr 2004 15:11:52 +0530


Hi ,

Please  Help.

I am using HttpClient and i am able to successfully send http request and
receive response.
But when i try to send https request for the same link i get the
following
error(I am able to successfully send https request and response through
the
browser.  ).

 javax.net.ssl.SSLException: Unrecognized SSL message, plaintext
connection?
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
at com.sun.net.ssl.internal.ssl.InputRecord.b(DashoA6275)
at com.sun.net.ssl.internal.ssl.InputRecord.read(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
org.apache.commons.httpclient.HttpConnection$WrappedOutputStream.write(Http
C
onnection.java:1347)
at
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:69)
at
java.io.BufferedOutputStream.flush(BufferedOutputStream.java:127)
at
org.apache.commons.httpclient.HttpConnection.flushRequestOutputStream(HttpC
o
nnection.java:782)
at
org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.ja
v
a:2173)
at
org.apache.commons.httpclient.HttpMethodBase.processRequest(HttpMethodBase.
j
ava:2528)
at
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:10
6
5)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:638)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:500)
at
com.travelocity.component.net.http.SimpleHttpConnectionManager.execute(Simp
l
eHttpConnectionManager.java:68)

I have tried the steps mentioned in SSL guide:
http://jakarta.apache.org/commons/httpclient/sslguide.html
with no luck.Can this happen if the certificate is not trusted .


My jdk version is 1.4 and

Please suggest steps to debug and bring it running.

Any help would be highly appreciated.

Thanks
Raj



-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]



-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]

RE: HttpClient for Https gives Unrecognized SSL message..

[Kalnichevski, Oleg]

 Could this happen coz of untrusted certificate from server.
 But in my code i have using EasySSLProtocolSocketFactory.

Not impossible, but unlikely. An untrusted certificate_should_ have caused a different 
error message.

A few more questions. What JDK/JRE are you using on the client side? What kind of web 
server are you running on the server? What is the SSL library used by the server?

Oleg


-Original Message-
From: Raj, Bhalla [mailto:[EMAIL PROTECTED]
Sent: Monday, April 19, 2004 17:25
To: Commons HttpClient Project
Subject: RE: HttpClient for Https gives Unrecognized SSL message..


Hi Oleg,

Many thanks for response.
I am performing SSL test(I may not able to run Test class ) .Mean while a
quick question.

Could this happen coz of untrusted certificate from server.
But in my code i have using EasySSLProtocolSocketFactory.

Protocol.registerProtocol(https, new Protocol(https, new
EasySSLProtocolSocketFactory(), 443));


Thanks
Raj

-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: Monday, April 19, 2004 8:21 PM
To: Commons HttpClient Project
Subject: RE: HttpClient for Https gives Unrecognized SSL message..



Raj,

Please note that HttpClient simply makes use of JSSE and does not attempt to
provide any sort of transport security by itself. As far as HttpClient is
concerned SSL is just a transport layer which is supposed to be completely
transparent to HttpClient. I'll do my best to help you out, but please note
this problem is VERY, VERY unlikely to be caused by HttpClient in the first
place. First and foremost you need to ensure that JSSE is properly
configured and is capable of communication with the target server.

Did you try the SSL test described in the troubleshooting section of the SSL
guide http://jakarta.apache.org/commons/httpclient/sslguide.html? If not,
please do so and let us know the result.


Oleg

-Original Message-
From: Raj, Bhalla [mailto:[EMAIL PROTECTED]
Sent: Monday, April 19, 2004 16:25
To: Commons HttpClient Project
Subject: RE: HttpClient for Https gives Unrecognized SSL message..


Hi Oleg,

Thanks for your response.

I am using from browser to connect to test this.
https://URL?method=book_hotelxml

and i get certificate to accept from browser and after accepting the
certificate
 i get proper XML response from server.

But when i do this from java client i get following error as mentioned

Caused by: javax.net.ssl.SSLException: Unrecognized SSL message, plaintext
connection?
at com.sun.net.ssl.internal.ssl.InputRecord.b(DashoA6275)
at com.sun.net.ssl.internal.ssl.InputRecord.read(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)

So i assume SSL is properly installed on server.

Pleas help.Another way to debug this.

Thanks
Raj

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, April 19, 2004 3:50 PM
To: Commons HttpClient Project
Subject: RE: HttpClient for Https gives Unrecognized SSL message..


Raj,
Are you sure that SSL is configured on the server side? Unrecognized SSL
message, plaintext connection? exception is usually thrown when an attempt
is made to connect SSLSocket to a plain HTTP port

Oleg


-- Original Message --
Reply-To: Commons HttpClient Project
[EMAIL PROTECTED]
From: Raj, Bhalla [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: HttpClient for Https gives Unrecognized SSL message..
Date: Mon, 19 Apr 2004 15:11:52 +0530


Hi ,

Please  Help.

I am using HttpClient and i am able to successfully send http request and
receive response.
But when i try to send https request for the same link i get the
following
error(I am able to successfully send https request and response through
the
browser.  ).

 javax.net.ssl.SSLException: Unrecognized SSL message, plaintext
connection?
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
at com.sun.net.ssl.internal.ssl.InputRecord.b(DashoA6275)
at com.sun.net.ssl.internal.ssl.InputRecord.read(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
org.apache.commons.httpclient.HttpConnection$WrappedOutputStream.write(Http
C
onnection.java:1347)
at
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:69)
at
java.io.BufferedOutputStream.flush(BufferedOutputStream.java:127)
at
org.apache.commons.httpclient.HttpConnection.flushRequestOutputStream(HttpC
o
nnection.java:782)
at
org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.ja
v

RE: HTTPClient request - DNS, connect, acknowledge, and download times in milliseconds

[Kalnichevski, Oleg]

Steve,
We already have a feature request to implement instrumentation for timings

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10815

Currently it is not very high on our list of priorities and is targeted for the 
release after the next one, which may take months or most likely years. I am afraid 
the fastest way to get what you want is to get hold of the source code and insert the 
required callbacks.

Oleg

-Original Message-
From: Steve Johnson [mailto:[EMAIL PROTECTED]
Sent: Friday, April 16, 2004 16:31
To: '[EMAIL PROTECTED]'
Subject: HTTPClient request - DNS, connect, acknowledge, and download
times in milliseconds


Hi All,

Am I sending this to the right place to have it added to the archives or put it in as 
a request?
This originally said microseconds, I meant milliseconds 1000=1 second.

Is there someone I could talk with about this subject?

I would like to request that DNS, connect, acknowledge, and download times in 
milliseconds (1000MS = 1 second)
be
available after a page is retrieved using HTTPClient or the method.

If this is not feasible then could the interfaces be exposed so that these times could 
be collected by calling
4 individual subroutines to do each action; DNS, connect, acknowledge, and download.

Thank you for your time and effort,
Steve



Steve Johnson
Software Engineer
Mercury Interactive
720 564 - 6532
USA, Canada and the Americas
720 564-6620
Hours: M-F 08:00-17:00 MST (Mountain Standard Time)

 http://www.mercuryinteractive.com http://www.mercuryinteractive.com
Looking for Answers to your SiteScope or SiteSeer questions?
http://support.mercuryinteractive.com
http://support.mercuryinteractive.com





***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [PATCH] SSL guide amendments (patch against 2.0 branch)

[Kalnichevski, Oleg]

Hi Eric
Many thanks for taking time to correct my writing. All corrections make sense to me. 
(BTW, no need to be over-diplomatic. I am perfectly aware that my English has its 
limits, especially if I just type away. Just correct it. There'll be no questions 
asked).

Do you still have the current CVS snapshot at your disposal? If yes, could you please 
recreate the patch with all those corrections, if that's not too much of a hassle?

Oleg

-Original Message-
From: Eric Johnson [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 15, 2004 15:18
To: Commons HttpClient Project
Cc: Daniel C. Amadei
Subject: Re: [PATCH] SSL guide amendments (patch against 2.0 branch)


Oleg,

A few suggested edits  I'm not a great editor myself (I frequently
miss bevies of typos when my spouse asks me to review her writing), but
since nobody else responded, I figured I would.

Hopefully, my edits make sense.

Oleg Kalnichevski wrote:

Folks,

Daniel C. Amadei has kindly contributed a paragraph on recently
discovered problem with bogus error messages caused by a bug in older
versions of Sun JSSE

I have also long promised to write a few words regarding the known
problems with IBM JSSE

Please let me know what you think. I would also like to kindly ask
someone of our resident native English speakers to proof-read the
writing

Cheers,

Oleg
PS: Daniel, I changed your original text somewhat. Please let me know if
you agree with the changes

 



Index: sslguide.xml
===
RCS file: /home/cvspublic/jakarta-commons/httpclient/xdocs/sslguide.xml,v
retrieving revision 1.2.2.1
diff -u -r1.2.2.1 sslguide.xml
--- sslguide.xml   21 Aug 2003 16:07:31 -  1.2.2.1
+++ sslguide.xml   14 Apr 2004 20:47:48 -
@@ -240,6 +240,45 @@
 /p
 /li

+li
+p
+ strongSocket timeout not correctly reported when using oder versions of 
JSSE

oder -- older
For that matter, how about JSSE prior to Java 1.4 incorrectly reports
socket timeout.

+ (prior to Java 1.4)/strong
+/p
+p
+ There is a bug in older versions of Sun JSSE that causes timed out read 
operation to report end of

Prior to Java 1.4, in Sun's JSSE implementation, a read operation that
has timed out incorrect reports end of

+ stream condition instead of throwing java.io.InterruptedIOException as 
expected. As a result if read
+ operation on a secure (SSL) connection times out (SO_TIMEOUT is set to a 
positive value) HttpClient

Replace starting from As a result..., HttpClient responds to this
exception by assuming that the connection was dropped and throws a
recoverable...

+ mistakingly assumes that the connection was dropped and throws a 
recoverable HTTP exception: Error in
+ parsing the status line from the response: unable to find line starting 
with HTTP instead of
+ java.io.InterruptedIOException: Read timed out as expected. If you get 
this message when working with

...starting with HTTP.  It should instead report
java.io.InterruptedIOException: Read timed out. If you see the unable
to find line... message when working with...

+ an older version of JDK and JSSE, it can be caused by the timeout waiting 
for data and not by a problem
+ with the connection.
+/p
+p
+ strongSolution:/strong One possible solution is to increase the timeout 
value as the server is

Solution -- more like Work-around

+ taking too long to start sending the response. Alternatively you may choose 
to upgrade to Java 1.4 or
+ above which does not exhibit this problem.
+/p
+p
+ The problem has been discovered and reported by Daniel C. Amadei.
+/p
+/li
+
+li
+p
+ strongHttpClient does not work with IBM JSSE shipped with IBM Websphere 
Application Platform/strong
+/p
+p
+ There is a bug in several releases of IBM JSSE that causes HttpClient to 
fail while detecting the size

Several releases of the IBM JSSE exhibit a bug that cause HttpClient...

+ of the socket send buffer (java.net.Socket.getSendBufferSize method throws 
java.net.SocketException:
+ Socket closed exception).
+/p
+p
+ strongSolution:/strong Make sure that you have all the latest fix packs 
applied. IBM Websphere
+ Application Server versions 4.0.6, 5.0.2.2, 5.1 have been reported to not 
exhibit the problem.

HttpClient users have reported that IBM Websphere ... , and 5.1 do not
exhibit the problem.

+/p
+/li
   /ol
 
 /section

 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Fwd: [VOTE][PROPOSAL][RESULT] Promote HttpClient to Jakarta Level

[Kalnichevski, Oleg]

Henri,

Jakarta commons did vote on this issue, though somewhat informally

http://marc.theaimsgroup.com/?t=10773881871r=1w=2

Oleg

-Original Message-
From: Henri Yandell [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 14, 2004 13:52
To: Jakarta Project Management Committee List
Cc: Commons HttpClient Project
Subject: Re: Fwd: [VOTE][PROPOSAL][RESULT] Promote HttpClient to Jakarta
Level



The PMC don't need to vote on it, just to be aware of it, for the Chair to
tell the board in his notes and to ratify the move. However, some may feel
that the vote should take place on commons-dev and not on
commons-httpclient-dev.

I'm +1 for the move, so not too bothered at where the vote has happened.

Hen

On Wed, 14 Apr 2004, Adrian Sutton wrote:


 Hi all,
 Recently the Commons HttpClient project voted on a proposal to move
 HttpClient out of Jakarta Commons to become a full Jakarta subproject.
 The result of the vote is below.  It's our understanding that the
 Jakarta PMC now needs to vote on the proposal as well.

 Please advise us of any step in this process we're missing.

 Regards,

 Adrian Sutton.


 Begin forwarded message:

  From: Adrian Sutton [EMAIL PROTECTED]
  Date: 29 March 2004 8:47:16 PM
  To: Commons HttpClient Project
  [EMAIL PROTECTED]
  Subject: [VOTE][PROPOSAL][RESULT] Promote HttpClient to Jakarta Level
  Reply-To: Commons HttpClient Project
  [EMAIL PROTECTED]
 
  The vote has passed.  We will put forth the proposal below to the
  Jakarta
  PMC to move HttpClient to a Jakarta level project.  The vote details
  are
  below:
 
  +1 votes -
  Adrian Sutton [EMAIL PROTECTED]
  Oleg Kalnichevski [EMAIL PROTECTED]
  Michael Becke [EMAIL PROTECTED]
  dIon Gillard [EMAIL PROTECTED]
 
  +0 votes -
  Ortwin Glück [EMAIL PROTECTED]
 
  Vote thread -
  http://nagoya.apache.org/eyebrowse/BrowseList?listName=commons-
  httpclient-de
  [EMAIL PROTECTED]by=threadfrom=681919
 
 
  (0) RATIONALE
  HTTP is the main protocol used today on the internet.  Although the JDK
  includes basic support for building HTTP-aware client applications, it
  doesn't provide the flexibility or ease of use needed for many
  projects.
 
  The current package in Jakarta-Commons is a widely used implementation
  with
  a strong community behind it.  The size of it's community and it's
  project
  has significantly outgrown the commons project and a move to a Jakarta
  level
  project would provide better support for that community and for the on
  going
  development of HttpClient.
 
  (1) SCOPE
  The project shall create and maintain a Java library implementing the
  client
  side of the HTTP 1.0 and 1.1 protocol, as defined in RFC 1945, RFC
  2616 and
  RFC 2617.
 
  HttpClient also supports the following RFCs.
 
  * RFC 2109 for HTTP state management mechanism (Cookies) - an upgrade
  to RFC
  2965 is planned for a future version of HttpClient
 
  * RFC 2396 Uniform Resoruce Identifiers (URI): Generic Syntax
 
  * RFC 1867 Form-based File Upload in HTML
 
  The package should:
 
  * Have an API which should be as simple to use as possible
  * Be as easy to extend as possible
  * Provide unconditional support for HTTP/1.1
 
  The package is quite different from the HTTP client provided as part
  of the
  JDK (java.net.HttpURLConnection), as it focuses on the HTTP methods
  being
  sent (instead of making that transparent to the user), and generally
  allows
  more interaction with the lower level connection.  The JDK client is
  also
  not very intuitive to use.
 
  The package is used by a wide range of projects both within the ASF
  and from
  third parties.  These include:
 
  * Jakarta Slide
  * Jakarta Commons Latka
  * Nortel Networks
  * HtmlUnit
  * Jakarta Cactus
  * JSR 147
  * NOSE Applied Intelligence ag
  * MindIQ's Design-a-Course
  * ContactOffice
  * Newknow
  * de4d2c
  * Furies
  * Term Highlighting for Verity Ultraseek search results
  * Mule - Universal Message Objects
  * many more.
 
  (1.5) Interaction With Other Packages
 
  HttpClient relies on:
 
  * Java Development Kit (Version 1.2 or later; 1.3 or later recommended)
  * Jakarta commons-logging (Version 1.0 or later)
  * Jakarta commons-codec (Version 1.2 or later)
 
  (2) INITIAL SOURCE OF THE PACKAGE
 
  The initial codebase exists as a sub-project of Jakarta-Commons, in the
  httpclient subdirectory of the jakarta-commons cvs tree.
 
  The proposed package name for the new sub-project is
  org.apache.httpclient.
 
  (3) REQUIRED JAKARTA RESOURCES
 
  * CVS Repository - New module, jakarta-httpclient in the CVS
  repository.
 
  * Initial Committers - The list is provided below.  All of the proposed
  committers are currently jakarta-commons committers.
 
  * Mailing List - Two new mailing lists will be required:
  [EMAIL PROTECTED] and
  [EMAIL PROTECTED]
  These will be used for developer discussions and user discussions
  respectively.  CVS commit messages will be sent to the httpclient-dev
  list.
 
  * 

RE: DO NOT REPLY [Bug 24869] - DigestScheme.authenticate returns invalid authorization string when algorithm is null

[Kalnichevski, Oleg]

No worries, Odi

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 15, 2004 16:18
To: [EMAIL PROTECTED]
Subject: DO NOT REPLY [Bug 24869] - DigestScheme.authenticate returns
invalid authorization string when algorithm is null


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=24869.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=24869

DigestScheme.authenticate returns invalid authorization string when algorithm is null

[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|[EMAIL PROTECTED]   |[EMAIL PROTECTED]
 Status|ASSIGNED|NEW



--- Additional Comments From [EMAIL PROTECTED]  2004-04-15 14:17 ---
Please take over, Oleg. I am really busy at the moment. Sorry for that.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [VOTE][PROPOSAL][RESULT] Promote HttpClient to Jakarta Level

[Kalnichevski, Oleg]

***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***
Adrian,
The message to [EMAIL PROTECTED] may not have gone through, as this is a restricted 
list (PMC members only). I believe we should try sending the proposal to [EMAIL 
PROTECTED] It appears the voting on HiveMind promotion, for instance, was held on that 
mailing list

Oleg

-Original Message-
From: Adrian Sutton [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 14, 2004 2:56
To: [EMAIL PROTECTED]
Cc: Commons HttpClient Project
Subject: Fwd: [VOTE][PROPOSAL][RESULT] Promote HttpClient to Jakarta
Level



Hi all,
Recently the Commons HttpClient project voted on a proposal to move
HttpClient out of Jakarta Commons to become a full Jakarta subproject.
The result of the vote is below.  It's our understanding that the
Jakarta PMC now needs to vote on the proposal as well.

Please advise us of any step in this process we're missing.

Regards,

Adrian Sutton.


Begin forwarded message:

 From: Adrian Sutton [EMAIL PROTECTED]
 Date: 29 March 2004 8:47:16 PM
 To: Commons HttpClient Project
 [EMAIL PROTECTED]
 Subject: [VOTE][PROPOSAL][RESULT] Promote HttpClient to Jakarta Level
 Reply-To: Commons HttpClient Project
 [EMAIL PROTECTED]

 The vote has passed.  We will put forth the proposal below to the
 Jakarta
 PMC to move HttpClient to a Jakarta level project.  The vote details
 are
 below:

 +1 votes -
 Adrian Sutton [EMAIL PROTECTED]
 Oleg Kalnichevski [EMAIL PROTECTED]
 Michael Becke [EMAIL PROTECTED]
 dIon Gillard [EMAIL PROTECTED]

 +0 votes -
 Ortwin Glück [EMAIL PROTECTED]

 Vote thread -
 http://nagoya.apache.org/eyebrowse/BrowseList?listName=commons-
 httpclient-de
 [EMAIL PROTECTED]by=threadfromh1919


 (0) RATIONALE
 HTTP is the main protocol used today on the internet.  Although the JDK
 includes basic support for building HTTP-aware client applications, it
 doesn't provide the flexibility or ease of use needed for many
 projects.

 The current package in Jakarta-Commons is a widely used implementation
 with
 a strong community behind it.  The size of it's community and it's
 project
 has significantly outgrown the commons project and a move to a Jakarta
 level
 project would provide better support for that community and for the on
 going
 development of HttpClient.

 (1) SCOPE
 The project shall create and maintain a Java library implementing the
 client
 side of the HTTP 1.0 and 1.1 protocol, as defined in RFC 1945, RFC
 2616 and
 RFC 2617.

 HttpClient also supports the following RFCs.

 * RFC 2109 for HTTP state management mechanism (Cookies) - an upgrade
 to RFC
 2965 is planned for a future version of HttpClient

 * RFC 2396 Uniform Resoruce Identifiers (URI): Generic Syntax

 * RFC 1867 Form-based File Upload in HTML

 The package should:

 * Have an API which should be as simple to use as possible
 * Be as easy to extend as possible
 * Provide unconditional support for HTTP/1.1

 The package is quite different from the HTTP client provided as part
 of the
 JDK (java.net.HttpURLConnection), as it focuses on the HTTP methods
 being
 sent (instead of making that transparent to the user), and generally
 allows
 more interaction with the lower level connection.  The JDK client is
 also
 not very intuitive to use.

 The package is used by a wide range of projects both within the ASF
 and from
 third parties.  These include:

 * Jakarta Slide
 * Jakarta Commons Latka
 * Nortel Networks
 * HtmlUnit
 * Jakarta Cactus
 * JSR 147
 * NOSE Applied Intelligence ag
 * MindIQ's Design-a-Course
 * ContactOffice
 * Newknow
 * de4d2c
 * Furies
 * Term Highlighting for Verity Ultraseek search results
 * Mule - Universal Message Objects
 * many more.

 (1.5) Interaction With Other Packages

 HttpClient relies on:

 * Java Development Kit (Version 1.2 or later; 1.3 or later recommended)
 * Jakarta commons-logging (Version 1.0 or later)
 * Jakarta commons-codec (Version 1.2 or later)

 (2) INITIAL SOURCE OF THE PACKAGE

 The initial codebase exists as a sub-project of Jakarta-Commons, in the
 httpclient subdirectory of the jakarta-commons cvs tree.

 The proposed package name for the new sub-project is
 org.apache.httpclient.

 (3) REQUIRED JAKARTA RESOURCES

 * CVS Repository - New module, jakarta-httpclient in the CVS
 repository.

 * 

FW: [NOTICE] HttpClient is requesting to move from commons to Jakarta sub-project

[Kalnichevski, Oleg]

The message attached below was sent to general at jakarta.apache.org. Apparently 
there's something brewing. You may know our fate soon.

Oleg

-Original Message-
From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 14, 2004 18:29
To: Jakarta General List
Subject: [NOTICE] HttpClient is requesting to move from commons to
Jakarta sub-project


All,

The HttpClient project has voted to ask to become a Jakarta
sub-project.  The PMC is voting on expanding Jakarta, and I personally
apologize to the community for accidentally holding the vote on the
private PMC list.  In order to keep confusion to to a minimum, we'll
keep it there and do better next time.

If anyone has any comments, speak now or forever hold it... :)

geir

--
Geir Magnusson Jr   203-247-1713(m)
[EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: HttpClient login error

[Kalnichevski, Oleg]

Gregory,
Does the site in question require authentication? If yes, it is quite likely you have 
hit one of the known limitations of the HttpClient 2.0 branch. See HttpClient SSL 
guide for details http://jakarta.apache.org/commons/httpclient/sslguide.html. This 
problem has already been fixed in the development (pre 3.0-alpha1) version.

However, to be really sure you may want to examine the wire log of the HTTP session 
and see what exactly goes wrong 
http://jakarta.apache.org/commons/httpclient/logging.html. Feel free to post the 
wire log to this mailing list if you think we may be of help. You should obfuscate 
sensitive data (such as user credentials and host names) before posting the log, 
though.

Oleg





-Original Message-
From: Grigorios Merenidis [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 07, 2004 18:20
To: [EMAIL PROTECTED]
Subject: HttpClient login error


Hi all!


I try to login on the site

http://www.mercedes-benz.t-online.de

but it is never successful.
I try to connect from my java application over a proxy to the destinated
server.
The connection over the proxy works fine.

My java code looks like this:

static final String LOGON_SITE = https://www.mercedes-benz.t-online.de;;
static final int LOGON_PORT = 443;
static final String authURL = /mb-portal/www/Forward;

HttpClient client = new HttpClient();
HostConfiguration hostConfiguration = new HostConfiguration();
try{
 client.setConnectionTimeout(6);
 client.setTimeout(3);
 hostConfiguration.setProxy(xx.yyy.zz.xxx, 80);
 client.setHostConfiguration(hostConfiguration);
 client.getHostConfiguration().setHost(LOGON_SITE,
 LOGON_PORT, https);
 client.getState().setCookiePolicy(CookiePolicy.COMPATIBILITY);
 GetMethod authget = new GetMethod();
 authget.setRequestHeader(userAgentHeader);
 authget.setFollowRedirects(true);
 client.executeMethod(authget);
 String responseBody = authget.getResponseBodyAsString();
 authget.releaseConnection();
 Cookie[] initCookies = client.getState().getCookies(LOGON_SITE,
LOGON_PORT, /, false);
 System.out.println(responseBody);
 if(initCookies.length==0){
  System.out.println(NONE in GET-Method:  + authget.getPath());
 }else{
 for (int z=0;zinitCookies.length;z++){
   System.out.println(-  + initCookies[z].toString());
  }
 }
 }catch(Exception ex){
System.out.println(ex.getMessage());
 }

   
 PostMethod authpost = new PostMethod(/mb-portal/www/Forward);
 NameValuePair userid = new NameValuePair(userName, myUserName);
 NameValuePair password = new NameValuePair(passwd, myPassword);
 authpost.setRequestBody(new NameValuePair[]{userid, password});
 authpost.setHostConfiguration(hostConfiguration);
 client.executeMethod(authpost);
 System.out.println(Login form post:  +
authpost.getStatusLine().toString());
 authpost.releaseConnection();
 Cookie[] logonCookies = client.getState().getCookies(LOGON_SITE,
LOGON_PORT, /, false);
 if(logonCookies.length==0){
  System.out.println(NONE IN POST-Method);
 }else{
  for (int z=0;zlogonCookies.length;z++){
System.out.println(-  + logonCookies[z].toString());
  }
 }
 int statuscode = authpost.getStatusCode();
 if ((statuscode==HttpStatus.SC_MOVED_TEMPORARILY)||
(statuscode==HttpStatus.SC_MOVED_PERMANENTLY)||
(statuscode==HttpStatus.SC_SEE_OTHER)||
(statuscode==HttpStatus.SC_TEMPORARY_REDIRECT)){
 Header header = authpost.getResponseHeader(location);
 if(header!=null){
String newuri = header.getValue();
if (newuri == nullnewuri.equals()){
  newuri = /;
  System.out.println(Redirect target:  + newuri);
  GetMethod redirect = new GetMethod(newuri);
  client.executeMethod(redirect);
}
redirect.releaseConnection();
  }else{
System.out.println(invalid redirect);
System.exit(1);
  }
  }
}

What I am doing wrong?
I would appreciate every help!!!

Thanks,

Gregory

--
NEU : GMX Internet.FreeDSL
Ab sofort DSL-Tarif ohne Grundgebühr: http://www.gmx.net/info


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this 

RE: Connection Pooling/Piplining

[Kalnichevski, Oleg]

Hi Vim
Are you absolutely sure you need all 100,000 threads running simultaneously? Probably 
you should approach the problem from a different angle and try to pool the worker 
threads rather than pooling HTTP connections?

Oleg

-Original Message-
From: Vimarsh Vasavada [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 01, 2004 9:27
To: Commons HttpClient Project
Subject: Connection Pooling/Piplining


Hello all.
We have following challenge to address :
1. We have 2 JBOSS Servers, say, S1 and S2
2. There will be 1,00,000 distinct-client-threads fired to
S1/TalkToS2.jsp/
3. S1 will have hence virtually 1,00,000-threads attempting to exchange
request/response with S2 only.

Now questions :
1. how do we realize Connection Pooling ?
2. Can MultiThreadedConnectionManager be of help to realize connection
pooling?
3. Since for all client-threads we need to make connection to single
server S2,can we realize Piplining?

Thanks in advance
vim


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Connection Pooling/Piplining

[Kalnichevski, Oleg]

Vim,

 1. Managing worker threads.[H/W,OS and App Server configuration is the
 place to find solution]

Having a pool of worker threads instead of spawning a dedicated thread per request / 
connection may well be a good investment for this kind of application. This is 
something HttpClient will not be able to help you with, though.

 2. Managing Connections between S1 and S2 is a second one..that's where
 I am baffled..as sun's raw implementation is not much of help to
 consider such load..

MultiThreadedConnectionManager does support connection pooling out of the box (so to 
speak). You can fine-tune the behaviour of the MultiThreadedConnectionManager class by 
defining the total maximum number of connections in the pool as well the maximum 
number of connections per host.

For more details see
http://jakarta.apache.org/commons/httpclient/threading.html

Hope this helps

Oleg

-Original Message-
From: Vimarsh Vasavada [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 01, 2004 10:56
To: Commons HttpClient Project
Subject: RE: Connection Pooling/Piplining


Well 1,00,000 threads is the worst-maximum-load-case.
But least-load case we evaluate is 1000 threads..
Problem is divisible into 2 sub-probs :
1. Managing worker threads.[H/W,OS and App Server configuration is the
place to find solution]
2. Managing Connections between S1 and S2 is a second one..that's where
I am baffled..as sun's raw implementation is not much of help to
consider such load..

HARDWARE PARAMETER SYSTEM
Class Server Class or Higher End Desktop
Processor PIV 2.4 GHz
Memory 1 GB RAM
Hard Disk IDE 40GB 7200 rpm
Network Dual LAN card (one for live IP and other for internal IP)

Application Server : jBoss 3.x with integrated Tomcat 4.x
JDK 1.3.1
HTTP Server : Apache 2.x with jBoss
RDBMS   : MS SQL Server 2000
O/S Windows 2000 Server with SP3



 -Original Message-
 From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
 Sent: Thursday, April 01, 2004 1:44 PM
 To: Commons HttpClient Project
 Subject: RE: Connection Pooling/Piplining


 Hi Vim
 Are you absolutely sure you need all 100,000 threads running
 simultaneously? Probably you should approach the problem from a
different
 angle and try to pool the worker threads rather than pooling HTTP
 connections?

 Oleg

 -Original Message-
 From: Vimarsh Vasavada [mailto:[EMAIL PROTECTED]
 Sent: Thursday, April 01, 2004 9:27
 To: Commons HttpClient Project
 Subject: Connection Pooling/Piplining


 Hello all.
 We have following challenge to address :
 1. We have 2 JBOSS Servers, say, S1 and S2
 2. There will be 1,00,000 distinct-client-threads fired to
 S1/TalkToS2.jsp/
 3. S1 will have hence virtually 1,00,000-threads attempting to
exchange
 request/response with S2 only.

 Now questions :
 1. how do we realize Connection Pooling ?
 2. Can MultiThreadedConnectionManager be of help to realize connection
 pooling?
 3. Since for all client-threads we need to make connection to single
 server S2,can we realize Piplining?

 Thanks in advance
 vim


 -
 To unsubscribe, e-mail: commons-httpclient-dev-
 [EMAIL PROTECTED]
 For additional commands, e-mail: commons-httpclient-dev-
 [EMAIL PROTECTED]




**
 *
 The information in this email is confidential and may be legally
 privileged.  Access to this email by anyone other than the intended
 addressee is unauthorized.  If you are not the intended recipient of
this
 message, any review, disclosure, copying, distribution, retention, or
any
 action taken or omitted to be taken in reliance on it is prohibited
and
 may be unlawful.  If you are not the intended recipient, please reply
to
 or forward a copy of this message to the sender and delete the
message,
 any attachments, and any copies thereof from your system.


**
 *

 -
 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]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete

RE: The httpclient.wire log.

[Kalnichevski, Oleg]

All right. I'll look into the problem this weekend and apply a fix.

Oleg

-Original Message-
From: Ortwin Glück [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 31, 2004 11:37
To: Commons HttpClient Project
Subject: Re: The httpclient.wire log.


Olge,

Geir is right. It is a bug to use an encoded reader since that will
convert all bytes not used by the encoding to question marks. His patch
fixes the problem. My idea was just to provide sort of nicer output.

Odi

Kalnichevski, Oleg wrote:

 Geir,
 The wirelog displays (is intedned to display) what gets physically transmitted 
 across the wire escaping all potentially non-printable characters, hence the 
 US-ASCII charset. What you see is what you get, sort of. I suspect that this is not 
 just the problem with the wire log display. I wonder if you set the charset in the 
 Content-Type header prior to executing the post method?


 http://jakarta.apache.org/commons/httpclient/charencodings.html

 Oleg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Tunneling non-HTTP through a web proxy with HttpClient

[Kalnichevski, Oleg]

All Mikes, Roland, and all
I believe it _might_ be possible to implement a generic SSL tunnelling mechanism using 
stock version of HttpClient. The only API change it may requite is adding protected 
HttpConnection#getSocket method. I may try to hack something up this weekend.

Oleg

-Original Message-
From: Michael Becke [mailto:[EMAIL PROTECTED]
Sent: Friday, March 26, 2004 14:44
To: Commons HttpClient Project
Subject: Re: Tunneling non-HTTP through a web proxy with HttpClient


 Hi Mike  Mike

:)

 Since CONNECT is also an HTTP method, it is not totally
 out of scope for the HttpClient. From RFC 2616, section 9.9:

Agreed.  CONNECT is definitely an HTTP method.  The only question is if
we should support it's use in non-HTTP contexts.

 Maybe we can consider official support for CONNECT
 as a feature for the big 4.0 API overhaul.

It seems like it could be a good addition.  My only hesitation is in
giving direct access to the Socket.  This seems like a pretty major
departure from our current system.

Mike


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Tunneling non-HTTP through a web proxy with HttpClient

[Kalnichevski, Oleg]

You are right. HttpClient uses tunnelling only when doing HTTPS. Hence the confusion.

-Original Message-
From: Roland Weber [mailto:[EMAIL PROTECTED]
Sent: Friday, March 26, 2004 15:03
To: Commons HttpClient Project
Subject: RE: Tunneling non-HTTP through a web proxy with HttpClient


Hi Oleg,

I guess it's just a typo, but to be sure:
The CONNECT method is for establishing a
generic tunnel through an HTTP proxy.
SSL tunneling is just one application of that.

cheers,
  Roland






Kalnichevski, Oleg [EMAIL PROTECTED]
26.03.2004 14:49
Please respond to Commons HttpClient Project

To: Commons HttpClient Project
[EMAIL PROTECTED]
cc:
Subject:RE: Tunneling non-HTTP through a web proxy with
HttpClient



All Mikes, Roland, and all
I believe it _might_ be possible to implement a generic SSL tunnelling
mechanism using stock version of HttpClient. The only API change it may
requite is adding protected HttpConnection#getSocket method. I may try to
hack something up this weekend.

Oleg

-Original Message-
From: Michael Becke [mailto:[EMAIL PROTECTED]
Sent: Friday, March 26, 2004 14:44
To: Commons HttpClient Project
Subject: Re: Tunneling non-HTTP through a web proxy with HttpClient


 Hi Mike  Mike

:)

 Since CONNECT is also an HTTP method, it is not totally
 out of scope for the HttpClient. From RFC 2616, section 9.9:

Agreed.  CONNECT is definitely an HTTP method.  The only question is if

we should support it's use in non-HTTP contexts.

 Maybe we can consider official support for CONNECT
 as a feature for the big 4.0 API overhaul.

It seems like it could be a good addition.  My only hesitation is in

giving direct access to the Socket.  This seems like a pretty major

departure from our current system.

Mike


-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]


***
The information in this email is confidential and may be legally
privileged.  Access to this email by anyone other than the intended
addressee is unauthorized.  If you are not the intended recipient of this
message, any review, disclosure, copying, distribution, retention, or any
action taken or omitted to be taken in reliance on it is prohibited and
may be unlawful.  If you are not the intended recipient, please reply to
or forward a copy of this message to the sender and delete the message,
any attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]



***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: question re: cookies

[Kalnichevski, Oleg]

Gil, Roland
Pluggable cookie policies as well as ability to manually set cookie headers are 
supported in the development branch only. For 2.0 there is no way around forking 
HttpClient

Oleg

-Original Message-
From: Roland Weber [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 25, 2004 8:39
To: Commons HttpClient Project
Subject: RE: question re: cookies


Ah yes, cookie headers that were manually set used
to get overridden. As far as I remember, that changed
a while back. Though I cannot tell whether the change
went into 2.0 or only into the development branch.

cheers,
  Roland






Alvarez, Gil [EMAIL PROTECTED]
25.03.2004 08:04
Please respond to Commons HttpClient Project

To: Commons HttpClient Project
[EMAIL PROTECTED]
cc:
Subject:RE: question re: cookies


Thanks, yes, the old code pulled it out of the header directly, but the
rest of the story is that I save that cookie for later submittal in a
url request. I tried using addRequestHeader(Cookie, ...) and that
didn't work. I surmised that it was because httpclient liked to operate
with higher-level abstractions, so I switched to using real Cookie
objects. I'd much rather do a getHeader()/setHeader() operation or
getCookie()/setCookie()operation; I don't want to mix the semantics
(such as getHeader()/setCookie()). Sounds like the cookie policy is the
way to go.

-Original Message-
From: Roland Weber [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 24, 2004 10:51 PM
To: Commons HttpClient Project
Subject: Re: question re: cookies

Hello Gil,

two options. If you only need to get the cookie for
your application, then access the header directly
instead of looking into the http state. That's probably
what your old code did, right?

Otherwise, implement and configure your own cookie
policy. Copy the default implementation that best fits
your needs, then modify the validity check for the
cookie path.
And don't forget to complain with the site admin
about the cookie standard violation.

You may first want to check whether there is an
alternative URL with path /X/b/c by which you can
query the cookie. There's got to be some reason
why the cookie is set with that path.

cheers,
  Roland





***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Httpclient + HTTPS + Proxy + BASIC Authentication

[Kalnichevski, Oleg]

John,
HttpClient will not/cannot attempt to authenticate with the target server until the 
transport layer (SSL tunnel) is up and running. It does not matter if pre-emptive 
authentication is used or not, SSL takes care of the transport security between the 
client and the target server. Only when authenticating against a proxy using Basic 
scheme, the proxy credentials are sent in clear

Oleg

-Original Message-
From: John Melody [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 24, 2004 13:58
To: Commons HttpClient Project
Subject: RE: Httpclient + HTTPS + Proxy + BASIC Authentication


Hi Oleg,

Thanks for your quick response.

Just to clarify one point - I am not concerned about authenticating
with the proxy - rather I need to do BASIC Authentication with the target
server and I am wondering if I use pre-emptive authentication is the
username
and password creditentials sent to the target server in clear text - before
the full SSL connection is in place.

So when I make the request to the URL i.e.
https://www.targetserver.com/document
via the proxy, the target server is going to come back looking for
username/password credentials becuase the document resource will require
this.
Httpclient will allow me to configure it so that it takes care of this
authentication request from the target server using

post.setDoAuthentication( true );

However, if I am using pre-emptive authentication, has the username and
password gone to the target server unsecured.

thanks for your help,

John


-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: 24 March 2004 13:26
To: Commons HttpClient Project
Subject: RE: Httpclient + HTTPS + Proxy + BASIC Authentication



John,

The connection between the client (the agent) and the proxy is always
unencrypted
regardless of the transport mechanism used to access the target server
(plain
or SSL). Therefore, when the Basic authentication scheme is used to
authenticate
with the proxy, the credentials are transmitted in clear case. To my
knowledge
none of the mainstream proxy servers currently implements transport security
between the client (the agent) and the proxy.

The HTTPS + Proxy + BASIC Authentication bug has been fixed in the
3.0-prealpha-nightly
version of HttpClient. Please note that this is unstable development version
and it is incompatible with 2.0 API. If things progress well, we may have
the first official alpha out by the of May for the public review of the new
3.0 API.

http://jakarta.apache.org/commons/httpclient/downloads.html

Cheers,

Oleg

-Original Message-
From: John Melody [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 24, 2004 13:36
To: [EMAIL PROTECTED]
Subject: Httpclient + HTTPS + Proxy + BASIC Authentication


Hi,

I have read the notes on the bug in Httpclient V2.0 to do with
using Basic Authentication with a HTTPS Url through a proxy.

One workaround proposed is to use preemptive authentication.

Are the credentials i.e. username, password sent unencrypted to the
target server when Preemptive Authentication is used even through the URL is
a https URL.

There are some notes about a PATCH being available for this problem.
If so, how do I get it - I am currently using HttpCLient V2.0. Can
this version be patched to fix the problem or must I move to a newer
version of httpclient to avail of the patch.

thanks for any help,
John.

regards,
John.
John Melody
SyberNet Ltd.
Galway Business Park,
Dangan,
Galway.
Tel. No. +353 91 514400
Fax. NO. +353 91 514409
Mobile - 087-2345847


-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]



***
The information in this email is confidential and may be legally privileged.
Access to this email by anyone other than the intended addressee is
unauthorized.  If you are not the intended recipient of this message, any
review, disclosure, copying, distribution, retention, or any action taken or
omitted to be taken in reliance on it is prohibited and may be unlawful.  If
you are not the intended recipient, please reply to or forward a copy of
this message to the sender and delete the message, any attachments, and any
copies thereof from your system.

***

-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
The information in this email is confidential and may be legally privileged.  Access

RE: [PROPOSAL][DRAFT] Promote HttpClient to Jakarta level

[Kalnichevski, Oleg]

---BeginMessage---
Folks,
I really think Java 1.3 does not bring anything to the table as far as HTTP 
communication is concerned. I am not even sure you we need Socket#shutdownOutput() at 
all. Currently HttpConnection#shutdownOutput is not used anywhere in HttpClient.

Java 1.4 is a totally different story. I've recently delved into New I/O and am 
convinced it would make a lot of sense for us if we do not use multiplexed I/O. New 
buffering primitives in java.nio package can drastically decrease object garbage 
collection and improve I/O buffering. 

This said, I do believe that Java 1.4 dependency is a little premature at this point. 
Upgrade to Java 1.4 should probably coincide with the 4.0 API redesign

Oleg


-Original Message-
From:   Roland Weber [mailto:[EMAIL PROTECTED]
Sent:   Thu 3/18/2004 13:51
To: Commons HttpClient Project
Cc: 
Subject:Re: [PROPOSAL][DRAFT]  Promote HttpClient to Jakarta level
Hello Adrian,

there is reflections stuff in:

HttpConnection - check for 1.3
HttpException - check for 1.4
util/ExceptionUtil - check for 1.4

You're right, if getting rid of the reflections
in HttpConnection is the only improvement,
there is no point in requiring JDK 1.3.

Does anyone else know about other parts of
the code where you would have liked to use
some 1.3 functionality? Improved collection
classes or so?

cheers,
  Roland






Adrian Sutton [EMAIL PROTECTED]
18.03.2004 13:27
Please respond to Commons HttpClient Project
 
To: Commons HttpClient Project 
[EMAIL PROTECTED]
cc: 
Subject:Re: [PROPOSAL][DRAFT]  Promote HttpClient to 
Jakarta level


On 18/3/04 10:24 PM, Roland Weber [EMAIL PROTECTED] wrote:

 (1.5) Interaction With Other Packages
 
 HttpClient relies on:
 
 * Java Development Kit (Version 1.2 or later; 1.3 or later recommended)
 
 I wonder whether this would be the right time
 to drop support for JDK 1.2 and require 1.3 ?

I generally find the right time is when there's a good reason to.  Was 
there
a 1.3 only method we wanted to use?  I know 1.4 has some cool stuff but
we're not going to be getting to use that for quite some time yet.

 cheers,
 Roland

Regards,

Adrian Sutton.

===
Kangaroo Point MarchFest is an annual festival of music, art, food and
culture, that aims to build community spirit and bring all types of
people together for a time of fun and entertainment.
Sat March 20th, midday till 10pm, at Kangaroo Point Uniting Church.
http://www.soulpurpose.com.au/marchfest
===


-
To unsubscribe, e-mail: 
[EMAIL PROTECTED]
For additional commands, e-mail: 
[EMAIL PROTECTED]





winmail.dat---End Message---
***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [PROPOSAL][DRAFT] Promote HttpClient to Jakarta level

[Kalnichevski, Oleg]

---BeginMessage---
(Some went badly wrong with my previous message. Damn Outlook. Retrying)


Folks,
I really think Java 1.3 does not bring anything to the table as far as HTTP 
communication is concerned. I am not even sure you we need Socket#shutdownOutput() at 
all. Currently HttpConnection#shutdownOutput is not used anywhere in HttpClient.

Java 1.4 is a totally different story. I've recently delved into New I/O and am 
convinced it would make a lot of sense for us if we do not use multiplexed I/O. New 
buffering primitives in java.nio package can drastically decrease object garbage 
collection and improve I/O buffering.

This said, I do believe that Java 1.4 dependency is a little premature at this point. 
Upgrade to Java 1.4 should probably coincide with the 4.0 API redesign

Oleg


-Original Message-
From:   Roland Weber [mailto:[EMAIL PROTECTED]
Sent:   Thu 3/18/2004 13:51
To: Commons HttpClient Project
Cc: 
Subject:Re: [PROPOSAL][DRAFT]  Promote HttpClient to Jakarta level
Hello Adrian,

there is reflections stuff in:

HttpConnection - check for 1.3
HttpException - check for 1.4
util/ExceptionUtil - check for 1.4

You're right, if getting rid of the reflections
in HttpConnection is the only improvement,
there is no point in requiring JDK 1.3.

Does anyone else know about other parts of
the code where you would have liked to use
some 1.3 functionality? Improved collection
classes or so?

cheers,
  Roland






Adrian Sutton [EMAIL PROTECTED]
18.03.2004 13:27
Please respond to Commons HttpClient Project
 
To: Commons HttpClient Project 
[EMAIL PROTECTED]
cc: 
Subject:Re: [PROPOSAL][DRAFT]  Promote HttpClient to 
Jakarta level


On 18/3/04 10:24 PM, Roland Weber [EMAIL PROTECTED] wrote:

 (1.5) Interaction With Other Packages
 
 HttpClient relies on:
 
 * Java Development Kit (Version 1.2 or later; 1.3 or later recommended)
 
 I wonder whether this would be the right time
 to drop support for JDK 1.2 and require 1.3 ?

I generally find the right time is when there's a good reason to.  Was 
there
a 1.3 only method we wanted to use?  I know 1.4 has some cool stuff but
we're not going to be getting to use that for quite some time yet.

 cheers,
 Roland

Regards,

Adrian Sutton.

===
Kangaroo Point MarchFest is an annual festival of music, art, food and
culture, that aims to build community spirit and bring all types of
people together for a time of fun and entertainment.
Sat March 20th, midday till 10pm, at Kangaroo Point Uniting Church.
http://www.soulpurpose.com.au/marchfest
===


-
To unsubscribe, e-mail: 
[EMAIL PROTECTED]
For additional commands, e-mail: 
[EMAIL PROTECTED]





winmail.dat---End Message---
***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]