httpclient-users@hc.apache.org Archives

Re: Calling servlet help (HttpClient 4.0)

2009-12-05T12:17:48Z

scook@seanet.com wrote:
> Can you expand on your answer a bit?  The accept header in the servlet or
> some API call (setRequest...() - what value?) in the http client?  The
> servlets set to return text/xml BTW.
> 
> I've also tried it using straight Java HttpUrlConnection, get same result.
> 
> Thanks for the help
> Steve
> 

Steve,

You need to know _exactly_ what kind of conversation session your web 
server expects. The usual way of approaching the problem would be to 
capture an HTTP session generated with a browser and then to simulate 
the same session with HttpClient

Oleg


>> Have you tried to set the "Accept" header of your request to the proper
>> media type ? Without it, your server might consider that you expect the
>> default, e.g. text/html, and won't serve you the xml. That's my guess.
>>
>> On 2 d�c. 2009, at 04:25, scook@seanet.com wrote:
>>
>>> Hi,
>>>
>>> Please excuse a newbie question but how do I get back the XML content
>>> back
>>> from a servlet.  All I seem to get is the index.html web page..
>>>
>>> Basic call is:
>>>
>>> HttpClient httpclient = new DefaultHttpClient();
>>> HttpGet httpget = new
>>>   HttpGet("http://localhost:8080/wc_server?task=get_results");
>>> HttpResponse response = httpclient.execute(httpget);
>>>
>>> HttpEntity entity = response.getEntity();
>>>
>>> if (entity != null)
>>> {
>>>    long len = entity.getContentLength();
>>>    if (len != -1 ) // && len < 8192)
>>>    {
>>>        System.out.println(EntityUtils.toString(entity));
>>>    }
>>> }
>>>
>>>
>>> Whats returned is the index.html page in that servlets top directory,
>>> not
>>> the XML data for that method call.  I get the same results with either:
>>>
>>> HttpGet("http://localhost:8080/wc_server?task=get_results");
>>>
>>> or
>>>
>>> HttpGet("http://localhost:8080/wc_server");
>>>
>>> It seems like it's not getting/processing the '?task=get_results'
>>>
>>> If I remove the index.html file from the servlet directory it just
>>> errors
>>> back...
>>>
>>> Thanks
>>> Steve Cook
>>> scook@seanet.com
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>>
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

Re: Setting cookie policy with HttpClient 4.0

2009-12-05T12:11:29Z

Ken Krugler wrote:
> Hi Oleg,
> 
> On Dec 3, 2009, at 2:40am, Oleg Kalnichevski wrote:
> 
>> On Wed, 2009-12-02 at 19:15 -0800, Ken Krugler wrote:
>>> Below is an email from August 7th, which I'm reviving due to this
>>> becoming a bigger issue over in Bixo-land.
>>>
>>> I've continued to run into this issue with my crawls, but so far I'm
>>> not doing anything with cookies, so it hasn't been a priority to track
>>> down.
>>>
>>> However another Bixo user also runs into it, and he noticed that by
>>> switching back to HttpClient 4.0-beta3, the warnings went away.
>>>
>>> I believe he just opened HTTPCLIENT-896 as a clone of HTTPCLIENT-773,
>>> which seemed to be this exact same bug (fixed by Oleg around 17/May/08).
>>>
>>> I'm wondering if the bug crept back into the code sometime between
>>> then and the final release.
>>>
>>> Thanks,
>>>
>>> -- Ken
>>>
>>
>> Hi Ken
>>
>> The cookie in question violates the format of 'expires' attribute
>> expected by the Netscape policy. One can configure the policy to be more
>> lenient about the format of 'expires' attribute by using a special HTTP
>> parameter. For details see HTTPCLIENT-896.
>>
>> It is not really a regression. I think the Netscape cookie policy was
>> made stricter at some point of time post 4.0-beta1
>>
>> Hope this clarifies the situation.
> 
> Thanks for the clarification, and the example code you added in a 
> comment to HTTPCLIENT-896.
> 
> Given the number of invalid cookies w/this issue that I see during a 
> crawl, would it make sense for the "best match" policy to select a more 
> lenient Netscape format?
> 
> Or maybe add a "best match-lenient" policy that does this?
> 
> I haven't had to do much in the way of cookie processing in the past, so 
> I'll confess up front that I'm ignorant about the potential issues that 
> could arise from using a more lenient policy.
> 
> Thanks again,
> 
> -- Ken
> 


Ken

I am somewhat reluctant to optimize HttpClient for just one particular 
use case, such as web crawling. Not only does the cookie in question 
violate the HTTP state management standards, it also violates the 
Netscape Draft spec. I do not think HttpClient should accept such 
cookies as valid per default. At the same time it is really easy to 
override the default behavior with just one parameter.

Cheers

Oleg


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

Re: Sending a large entity causes the client to close the connection

2009-12-05T12:03:00Z

Malte Ried wrote:
> Hi!
> 
> I'm trying to write a simple server application. It must be able to
> serve a big entity (about 45kb) to the client, which is a JBoss
> Application Server in my case. Sending the entity results in a
> connection reset. I'm not sure why this happens. Maybe the client side
> input buffer is not big enough, so the client closes the connection.
> 
> This is what I use:
> 
> HttpResponse response = new BasicHttpResponse(statusLine);
> 
> //set the header with response.addHeader(...);
> 
> StringEntity entity = new StringEntity(data, encoding);
> response.setEntity(entity);
> 
> serverConnection.sendResponseHeader(response);
> serverConnection.sendResponseEntity(response);
> 
> If I use a very simple client app which just opens a socket and prints
> all received data to the console, everything looks right. I also sniffed
> the communication between the JBoss and another server which serves the
> same data as I would like to serve. This data is sent in many small
> chunks (<500 bytes). If I shorten the data to that size, everything
> works (beside the data which is missing, of course).
> 
> I also tried to use chunked transfer coding but since the
> ChunkedOutputStream.write does not split the data, nothing changes.
> 
> So, the main question is: How do I send a large entity in small chunks?
> Or did I miss something else?
> 

HttpCore can deal with content entities of unlimited length, much, much 
larger than 45kb

Frankly, I do not understand what it is exactly you are trying to do. 
Why do not you just use HttpService and let it deal with content chunking?

http://svn.apache.org/repos/asf/httpcomponents/httpcore/branches/4.0.x/httpcore/src/examples/org/apache/http/examples/ElementalHttpServer.java

Oleg

> Thanks in advance for every help / comment!
> 
> Best regards,
> 
> Malte
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

Re: Calling servlet help (HttpClient 4.0)

2009-12-04T09:47:24Z

Well, the idea is to try to set the "Accept" header of the request, so that the media type
requested is compatible with what the servlets are configured to serve:

HttpGet httpget = new HttpGet("...");
httpget.setRequestHeader("Accept", "text/xml");

If it still doesn't work, try to tweak the media type, i.e. "application/xml", ...

You can learn more about the Accept header in RFC 2616, section 14.1.

Hope this helps.

On 4 d�c. 2009, at 03:59, scook@seanet.com wrote:

> Can you expand on your answer a bit?  The accept header in the servlet or
> some API call (setRequest...() - what value?) in the http client?  The
> servlets set to return text/xml BTW.
> 
> I've also tried it using straight Java HttpUrlConnection, get same result.
> 
> Thanks for the help
> Steve
> 
>> Have you tried to set the "Accept" header of your request to the proper
>> media type ? Without it, your server might consider that you expect the
>> default, e.g. text/html, and won't serve you the xml. That's my guess.
>> 
>> On 2 d�c. 2009, at 04:25, scook@seanet.com wrote:
>> 
>>> Hi,
>>> 
>>> Please excuse a newbie question but how do I get back the XML content
>>> back
>>> from a servlet.  All I seem to get is the index.html web page..
>>> 
>>> Basic call is:
>>> 
>>> HttpClient httpclient = new DefaultHttpClient();
>>> HttpGet httpget = new
>>>  HttpGet("http://localhost:8080/wc_server?task=get_results");
>>> HttpResponse response = httpclient.execute(httpget);
>>> 
>>> HttpEntity entity = response.getEntity();
>>> 
>>> if (entity != null)
>>> {
>>>   long len = entity.getContentLength();
>>>   if (len != -1 ) // && len < 8192)
>>>   {
>>>       System.out.println(EntityUtils.toString(entity));
>>>   }
>>> }
>>> 
>>> 
>>> Whats returned is the index.html page in that servlets top directory,
>>> not
>>> the XML data for that method call.  I get the same results with either:
>>> 
>>> HttpGet("http://localhost:8080/wc_server?task=get_results");
>>> 
>>> or
>>> 
>>> HttpGet("http://localhost:8080/wc_server");
>>> 
>>> It seems like it's not getting/processing the '?task=get_results'
>>> 
>>> If I remove the index.html file from the servlet directory it just
>>> errors
>>> back...
>>> 
>>> Thanks
>>> Steve Cook
>>> scook@seanet.com

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

Re: Calling servlet help (HttpClient 4.0)

2009-12-04T02:59:24Z

Can you expand on your answer a bit?  The accept header in the servlet or
some API call (setRequest...() - what value?) in the http client?  The
servlets set to return text/xml BTW.

I've also tried it using straight Java HttpUrlConnection, get same result.

Thanks for the help
Steve

> Have you tried to set the "Accept" header of your request to the proper
> media type ? Without it, your server might consider that you expect the
> default, e.g. text/html, and won't serve you the xml. That's my guess.
>
> On 2 d�c. 2009, at 04:25, scook@seanet.com wrote:
>
>> Hi,
>>
>> Please excuse a newbie question but how do I get back the XML content
>> back
>> from a servlet.  All I seem to get is the index.html web page..
>>
>> Basic call is:
>>
>> HttpClient httpclient = new DefaultHttpClient();
>> HttpGet httpget = new
>>   HttpGet("http://localhost:8080/wc_server?task=get_results");
>> HttpResponse response = httpclient.execute(httpget);
>>
>> HttpEntity entity = response.getEntity();
>>
>> if (entity != null)
>> {
>>    long len = entity.getContentLength();
>>    if (len != -1 ) // && len < 8192)
>>    {
>>        System.out.println(EntityUtils.toString(entity));
>>    }
>> }
>>
>>
>> Whats returned is the index.html page in that servlets top directory,
>> not
>> the XML data for that method call.  I get the same results with either:
>>
>> HttpGet("http://localhost:8080/wc_server?task=get_results");
>>
>> or
>>
>> HttpGet("http://localhost:8080/wc_server");
>>
>> It seems like it's not getting/processing the '?task=get_results'
>>
>> If I remove the index.html file from the servlet directory it just
>> errors
>> back...
>>
>> Thanks
>> Steve Cook
>> scook@seanet.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

how to post using same session?

2009-12-03T21:56:42Z

hi,

lets say there is a web page requesting,
-personalID
-sequence of numbers (written image, but assume its just plain text)


i can parse and get the sequence, however i dont know how to post form with the values?

(the sequence in post method changes)


here is the code, any help would be appreciated..


importorg.apache.commons.httpclient.HttpClient;importorg.apache.commons.httpclient.NameValuePair;importorg.apache.commons.httpclient.cookie.CookiePolicy;importorg.apache.commons.httpclient.methods.GetMethod;importorg.apache.commons.httpclient.methods.PostMethod;public
String contents=
String urlAddress = 
HttpClient client = 
client.getParams().setCookiePolicy(
CookiePolicy.
* String key = "";
* 
* URL url = new URL(urlAddress); URLConnection conn =
* url.openConnection(); DataInputStream in = new
* DataInputStream(conn.getInputStream()); BufferedReader d = new
* BufferedReader(new InputStreamReader(in)); StringBuffer buffer =
* new StringBuffer(); while (d.ready()) {
* buffer.append(d.readLine()); }
* 
* int index = -1; String contents = buffer.toString(); index =
* contents.indexOf("mp3sesler"); while (index > -1) { key = key +
* contents.substring(index + 10, index + 11); index =
* contents.indexOf("mp3sesler", index + 11); }
* 
* System.out.println(contents); System.out.println(key);
*/classClient {publicstaticvoidmain(String[] args) {try{intstatusCode, index;"", key="";"http://app.sgk.gov.tr/SigortaliHizmet/jsp/tcGir.jsp";newHttpClient();BROWSER_COMPATIBILITY);/*GetMethod
getMethod = 
getMethod.getParams().setCookiePolicy(CookiePolicy.
statusCode = client.executeMethod(getMethod);
contents = getMethod.getResponseBodyAsString();
getMethod.releaseConnection();
index = -1;
index = contents.indexOf(
key = key + contents.substring(index + 10, index + 11);
index = contents.indexOf(
}
System.
System.
}
PostMethod postMethod = 
NameValuePair[] data = { 
postMethod.addParameters(data);newGetMethod(urlAddress);RFC_2109);if(statusCode != -1) {"mp3sesler");while(index
> -1) {"mp3sesler", index + 11);out.println(contents);out.println(key);newPostMethod(urlAddress);newNameValuePair("tckno",
"11111111111"),newNameValuePair("akey", key),newNameValuePair("tcknodanSicilOgren", "tcknovar"),newNameValuePair("sorgu1",
"Sigortalı Ara") };// Configure the form parameters* method.addParameter("tckno", "11111111111");
* method.addParameter("akey", "4113");
* method.addParameter("tcknodanSicilOgren", "tcknovar");
* method.addParameter("sorgu1", "Sigortalı Ara");
*//*// Execute the POST methodstatusCode = client.executeMethod(postMethod);
contents = postMethod.getResponseBodyAsString();
postMethod.releaseConnection();
System.
}
} 
e.printStackTrace();
}
}if(statusCode != -1) {out.println(contents);catch(Exception e) { 


      

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

Re: Setting cookie policy with HttpClient 4.0

2009-12-03T18:14:56Z

Hi Oleg,

On Dec 3, 2009, at 2:40am, Oleg Kalnichevski wrote:

> On Wed, 2009-12-02 at 19:15 -0800, Ken Krugler wrote:
>> Below is an email from August 7th, which I'm reviving due to this
>> becoming a bigger issue over in Bixo-land.
>>
>> I've continued to run into this issue with my crawls, but so far I'm
>> not doing anything with cookies, so it hasn't been a priority to  
>> track
>> down.
>>
>> However another Bixo user also runs into it, and he noticed that by
>> switching back to HttpClient 4.0-beta3, the warnings went away.
>>
>> I believe he just opened HTTPCLIENT-896 as a clone of HTTPCLIENT-773,
>> which seemed to be this exact same bug (fixed by Oleg around 17/May/ 
>> 08).
>>
>> I'm wondering if the bug crept back into the code sometime between
>> then and the final release.
>>
>> Thanks,
>>
>> -- Ken
>>
>
> Hi Ken
>
> The cookie in question violates the format of 'expires' attribute
> expected by the Netscape policy. One can configure the policy to be  
> more
> lenient about the format of 'expires' attribute by using a special  
> HTTP
> parameter. For details see HTTPCLIENT-896.
>
> It is not really a regression. I think the Netscape cookie policy was
> made stricter at some point of time post 4.0-beta1
>
> Hope this clarifies the situation.

Thanks for the clarification, and the example code you added in a  
comment to HTTPCLIENT-896.

Given the number of invalid cookies w/this issue that I see during a  
crawl, would it make sense for the "best match" policy to select a  
more lenient Netscape format?

Or maybe add a "best match-lenient" policy that does this?

I haven't had to do much in the way of cookie processing in the past,  
so I'll confess up front that I'm ignorant about the potential issues  
that could arise from using a more lenient policy.

Thanks again,

-- Ken

--------------------------------------------
Ken Krugler
+1 530-210-6378
http://bixolabs.com
e l a s t i c   w e b   m i n i n g





---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

Sending a large entity causes the client to close the connection

2009-12-03T18:06:38Z

Hi!

I'm trying to write a simple server application. It must be able to
serve a big entity (about 45kb) to the client, which is a JBoss
Application Server in my case. Sending the entity results in a
connection reset. I'm not sure why this happens. Maybe the client side
input buffer is not big enough, so the client closes the connection.

This is what I use:

HttpResponse response = new BasicHttpResponse(statusLine);

//set the header with response.addHeader(...);

StringEntity entity = new StringEntity(data, encoding);
response.setEntity(entity);

serverConnection.sendResponseHeader(response);
serverConnection.sendResponseEntity(response);

If I use a very simple client app which just opens a socket and prints
all received data to the console, everything looks right. I also sniffed
the communication between the JBoss and another server which serves the
same data as I would like to serve. This data is sent in many small
chunks (<500 bytes). If I shorten the data to that size, everything
works (beside the data which is missing, of course).

I also tried to use chunked transfer coding but since the
ChunkedOutputStream.write does not split the data, nothing changes.

So, the main question is: How do I send a large entity in small chunks?
Or did I miss something else?

Thanks in advance for every help / comment!

Best regards,

Malte

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

Re: Setting cookie policy with HttpClient 4.0

2009-12-03T10:40:11Z

On Wed, 2009-12-02 at 19:15 -0800, Ken Krugler wrote:
> Below is an email from August 7th, which I'm reviving due to this  
> becoming a bigger issue over in Bixo-land.
> 
> I've continued to run into this issue with my crawls, but so far I'm  
> not doing anything with cookies, so it hasn't been a priority to track  
> down.
> 
> However another Bixo user also runs into it, and he noticed that by  
> switching back to HttpClient 4.0-beta3, the warnings went away.
> 
> I believe he just opened HTTPCLIENT-896 as a clone of HTTPCLIENT-773,  
> which seemed to be this exact same bug (fixed by Oleg around 17/May/08).
> 
> I'm wondering if the bug crept back into the code sometime between  
> then and the final release.
> 
> Thanks,
> 
> -- Ken
> 

Hi Ken

The cookie in question violates the format of 'expires' attribute
expected by the Netscape policy. One can configure the policy to be more
lenient about the format of 'expires' attribute by using a special HTTP
parameter. For details see HTTPCLIENT-896.

It is not really a regression. I think the Netscape cookie policy was
made stricter at some point of time post 4.0-beta1   

Hope this clarifies the situation.

Cheers,

Oleg


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

Setting cookie policy with HttpClient 4.0

2009-12-03T03:15:59Z

Below is an email from August 7th, which I'm reviving due to this  
becoming a bigger issue over in Bixo-land.

I've continued to run into this issue with my crawls, but so far I'm  
not doing anything with cookies, so it hasn't been a priority to track  
down.

However another Bixo user also runs into it, and he noticed that by  
switching back to HttpClient 4.0-beta3, the warnings went away.

I believe he just opened HTTPCLIENT-896 as a clone of HTTPCLIENT-773,  
which seemed to be this exact same bug (fixed by Oleg around 17/May/08).

I'm wondering if the bug crept back into the code sometime between  
then and the final release.

Thanks,

-- Ken

= 
= 
= 
= 
= 
= 
= 
= 
= 
= 
= 
= 
= 
= 
= 
= 
= 
= 
= 
= 
= 
= 
= 
= 
= 
= 
= 
= 
= 
= 
= 
= 
= 
= 
= 
= 
========================================================================

Hi all,

I'm seeing errors in my logs relating to parsing the expires date  
value in a cookie:

09/08/07 10:26:46 WARN protocol.ResponseProcessCookies:137 - Invalid  
cookie header: "Set-Cookie: IU=deleted; expires=Thu, 07 Aug 2008  
17:26:45 GMT; path=/; domain=.yahoo.com". Unable to parse expires  
attribute: Thu, 07 Aug 2008 17:26:45 GMT

I looked through the HtttpClient source, and it seems like if I've set  
up my cookie policy properly, the above date would be parsed properly.

Here's now I'm setting up the cookie policy:

=================================================================
HttpParams params = new BasicHttpParams();
...
CookieSpecParamBean cookieParams = new CookieSpecParamBean(params);
cookieParams.setSingleHeader(true);
...
ClientConnectionManager cm = new ThreadSafeClientConnManager(params,  
schemeRegistry);
DefaultHttpClient httpClient = new DefaultHttpClient(cm, params);
...
params = httpClient.getParams();
HttpClientParams.setCookiePolicy(params, CookiePolicy.BEST_MATCH);
=================================================================

But the above code was assembled from a few different snippets online,  
IIRC. So maybe this isn't correct.

For example, in the "Choosing Cookie Policy" section of the tutorial  
docs, it uses the setParameter() API to set the policy:

httpclient.getParams().setParameter(ClientPNames.COOKIE_POLICY,  
CookiePolicy.RFC_2965);

I assume the two are equivalent, but any input would be appreciated.

Thanks,

-- Ken

--------------------------------------------

+1 530-265-2225




--------------------------
Ken Krugler
TransPac Software, Inc.

+1 530-210-6378


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

Re: Calling servlet help (HttpClient 4.0)

2009-12-02T09:13:22Z

Have you tried to set the "Accept" header of your request to the proper media type ? Without
it, your server might consider that you expect the default, e.g. text/html, and won't serve
you the xml. That's my guess.

On 2 d�c. 2009, at 04:25, scook@seanet.com wrote:

> Hi,
> 
> Please excuse a newbie question but how do I get back the XML content back
> from a servlet.  All I seem to get is the index.html web page..
> 
> Basic call is:
> 
> HttpClient httpclient = new DefaultHttpClient();
> HttpGet httpget = new
>   HttpGet("http://localhost:8080/wc_server?task=get_results");
> HttpResponse response = httpclient.execute(httpget);
> 
> HttpEntity entity = response.getEntity();
> 
> if (entity != null)
> {
>    long len = entity.getContentLength();
>    if (len != -1 ) // && len < 8192)
>    {
>        System.out.println(EntityUtils.toString(entity));
>    }
> }
> 
> 
> Whats returned is the index.html page in that servlets top directory, not
> the XML data for that method call.  I get the same results with either:
> 
> HttpGet("http://localhost:8080/wc_server?task=get_results");
> 
> or
> 
> HttpGet("http://localhost:8080/wc_server");
> 
> It seems like it's not getting/processing the '?task=get_results'
> 
> If I remove the index.html file from the servlet directory it just errors
> back...
> 
> Thanks
> Steve Cook
> scook@seanet.com

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

Re: HTTP URI Percent Encoding ?

2009-12-02T09:08:22Z

What about the java.net.URLEncoder ? It behaves slightly differently from what is described
in RFC-3986 (translates the space char as + instead of %20), but may be it will do the job
for you ?

If you want "true" URI escaping, maybe you should take a look at http://code.google.com/p/gdata-java-client/source/browse/trunk/java/src/com/google/gdata/util/common/base/CharEscapers.java
and its uriEscaper(..). Not tried in practice, but it looks good.

-- CFR

On 2 d�c. 2009, at 08:03, Eduardo Martins wrote:

> Hello, does the new HTTP Client API provides any means for percent encoding
> the request URI ?
> 
> -- Eduardo
> 
> -:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-
> http://emmartins.blogspot.com

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

HTTP URI Percent Encoding ?

2009-12-02T07:03:23Z

Hello, does the new HTTP Client API provides any means for percent encoding
the request URI ?

-- Eduardo

-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-
http://emmartins.blogspot.com

Calling servlet help (HttpClient 4.0)

2009-12-02T03:25:15Z

Hi,

Please excuse a newbie question but how do I get back the XML content back
from a servlet.  All I seem to get is the index.html web page..

Basic call is:

HttpClient httpclient = new DefaultHttpClient();
HttpGet httpget = new
   HttpGet("http://localhost:8080/wc_server?task=get_results");
HttpResponse response = httpclient.execute(httpget);

HttpEntity entity = response.getEntity();

if (entity != null)
{
    long len = entity.getContentLength();
    if (len != -1 ) // && len < 8192)
    {
        System.out.println(EntityUtils.toString(entity));
    }
}


Whats returned is the index.html page in that servlets top directory, not
the XML data for that method call.  I get the same results with either:

HttpGet("http://localhost:8080/wc_server?task=get_results");

or

HttpGet("http://localhost:8080/wc_server");

It seems like it's not getting/processing the '?task=get_results'

If I remove the index.html file from the servlet directory it just errors
back...

Thanks
Steve Cook
scook@seanet.com


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

Re: implementation of a custom HttpRoutePlanner - how to choose the HttpRoute attributes (secure, tunnel type, and layer type)?

2009-12-01T20:37:09Z

Stefan Wachter wrote:
> Hi Oleg,
> 
> I am sorry for bothering you. I think I understand now. In order to have
> an https connection to a target host via a proxy the proxy is accessed
> by http marking the route as being secure, tunneled, and layered. Thank
> your for making this clear to me.
> 
> This leaves me with the SSLPeerUnverifiedException. I switched on SSL
> debugging by setting "-Djavax.net.debug=all". From the log it seems that
> the problem is caused by the certificate that the proxy server uses. In
> a former post you asked if the CONNECT succeedes. As far as I can
> interpret the log it seems that the CONNECT fails.

Post the log

  The target host I
> want to reach (https://www.gmx.net) does not appear in the log at all.
> 
> I do not understand why the certificate of the proxy does matter. After
> all the connection to the proxy should be done by http.
> 

It is very likely that the proxy inserts itself as a man-in-the-middle 
by intercepting and rewriting SSL packets.


> (BTW: If I use the proxy by a browser I can access the target host
> https://www.gmx.net.)
> 
> Please give me some more insight!
> 
> Cheers,
> --Stefan
> 
> *** Certificate chain
> chain [0] = [
> [
>   Version: V3
>   Subject: EMAILADDRESS=owasp-webscarab@lists.sourceforge.net,
> CN=WebScarab, OU=WebScarab, O=Open Web Application Security Project,
> L=Johannesburg, ST=Gauteng, C=ZA
>   Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
> 

Is this certificate trusted? I am pretty sure it is not trusted by JRE 
per default.


>   Key:  Sun RSA public key, 1024 bits
>   modulus:
> 154623964938145369797219612839395417706134608433089443549809415871369366723673817041648156759869165956480706191296755342245066633311162904277499876116164772710364652941103434840470861083851860427495958630646686012271912459851197852364216947956958537100938424770176632556183958666972394630932757389391348203517
>   public exponent: 65537
>   Validity: [From: Thu Apr 01 14:45:59 CEST 2004,
>                To: Sun Mar 30 14:45:59 CEST 2014]
>   Issuer: EMAILADDRESS=owasp-webscarab@lists.sourceforge.net,
> CN=WebScarab, OU=WebScarab, O=Open Web Application Security Project,
> L=Johannesburg, ST=Gauteng, C=ZA
>   SerialNumber: [    00]
> 
> Certificate Extensions: 3
> [1]: ObjectId: 2.5.29.14 Criticality=false
> SubjectKeyIdentifier [
> KeyIdentifier [
> 0000: C5 2E DC 77 1B 2D 4B A5   C9 F7 79 E9 26 38 5C D2  ...w.-K...y.&8\.
> 0010: 3B C5 46 88                                        ;.F.
> ]
> ]
> 
> [2]: ObjectId: 2.5.29.35 Criticality=false
> AuthorityKeyIdentifier [
> KeyIdentifier [
> 0000: C5 2E DC 77 1B 2D 4B A5   C9 F7 79 E9 26 38 5C D2  ...w.-K...y.&8\.
> 0010: 3B C5 46 88                                        ;.F.
> ]
> 
> [EMAILADDRESS=owasp-webscarab@lists.sourceforge.net, CN=WebScarab,
> OU=WebScarab, O=Open Web Application Security Project, L=Johannesburg,
> ST=Gauteng, C=ZA]
> SerialNumber: [    00]
> ]
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

Re: ClientAuthentication example java.lang.NoClassDefFoundError

2009-12-01T15:22:48Z

Andreas Ernst schrieb:
> Hi,
> 
> i tried the example ClientAuthentication, but the example throws an 
> exception:
> 
> run:
> Exception in thread "main" java.lang.NoClassDefFoundError: 
> org/apache/commons/logging/LogFactory
>         at 
> org.apache.http.impl.client.AbstractHttpClient.(AbstractHttpClient.java:159)

> 
>         at 
> org.apache.http.impl.client.DefaultHttpClient.(DefaultHttpClient.java:178)

> 
>         at 
> org.apache.http.examples.client.ClientAuthentication.main(ClientAuthentication.java:28)

> 
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.commons.logging.LogFactory
>         at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:303)
>         at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:316)
>         ... 3 more
> Java Result: 1
> ERSTELLEN ERFOLGREICH (Gesamtzeit: 0 Minuten 0 Sekunden)
> 
> 
> The class org.apache.commons.logging.LogFactory is not found at this line:
> 
> DefaultHttpClient httpclient = new DefaultHttpClient();
> 
> I looked into the source code, but i did not find any logger definition.
> 
> Any hints?

ok, there are several dependencies, so i use the

httpcomponents-client-4.0-bin-with-dependencies.zip

within my classpath and i worked.

-- 
Andreas Ernst - IT Spektrum
Postfach 5, 65612 Beselich
Schupbacher Str. 32, 65614 Beselich, Germany
Tel: +49-6484-91002 Fax: +49-6484-91003
ae@ae-online.de www.ae-online.de
www.tachyon-online.de

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

ClientAuthentication example java.lang.NoClassDefFoundError

2009-12-01T11:00:07Z

Hi,

i tried the example ClientAuthentication, but the example throws an 
exception:

run:
Exception in thread "main" java.lang.NoClassDefFoundError: 
org/apache/commons/logging/LogFactory
         at 
org.apache.http.impl.client.AbstractHttpClient.(AbstractHttpClient.java:159)
         at 
org.apache.http.impl.client.DefaultHttpClient.(DefaultHttpClient.java:178)
         at 
org.apache.http.examples.client.ClientAuthentication.main(ClientAuthentication.java:28)
Caused by: java.lang.ClassNotFoundException: 
org.apache.commons.logging.LogFactory
         at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
         at java.security.AccessController.doPrivileged(Native Method)
         at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
         at java.lang.ClassLoader.loadClass(ClassLoader.java:303)
         at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
         at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:316)
         ... 3 more
Java Result: 1
ERSTELLEN ERFOLGREICH (Gesamtzeit: 0 Minuten 0 Sekunden)


The class org.apache.commons.logging.LogFactory is not found at this line:

DefaultHttpClient httpclient = new DefaultHttpClient();

I looked into the source code, but i did not find any logger definition.

Any hints?

regards
Andreas
-- 
Andreas Ernst - IT Spektrum
Postfach 5, 65612 Beselich
Schupbacher Str. 32, 65614 Beselich, Germany
Tel: +49-6484-91002 Fax: +49-6484-91003
ae@ae-online.de www.ae-online.de
www.tachyon-online.de

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

Re: implementation of a custom HttpRoutePlanner - how to choose the HttpRoute attributes (secure, tunnel type, and layer type)?

2009-12-01T10:06:51Z

Hi Oleg,

I am sorry for bothering you. I think I understand now. In order to have
an https connection to a target host via a proxy the proxy is accessed
by http marking the route as being secure, tunneled, and layered. Thank
your for making this clear to me.

This leaves me with the SSLPeerUnverifiedException. I switched on SSL
debugging by setting "-Djavax.net.debug=all". From the log it seems that
the problem is caused by the certificate that the proxy server uses. In
a former post you asked if the CONNECT succeedes. As far as I can
interpret the log it seems that the CONNECT fails. The target host I
want to reach (https://www.gmx.net) does not appear in the log at all.

I do not understand why the certificate of the proxy does matter. After
all the connection to the proxy should be done by http.

(BTW: If I use the proxy by a browser I can access the target host
https://www.gmx.net.)

Please give me some more insight!

Cheers,
--Stefan

PS: Here is the SSL log. I omitted the first lines where lots of trusted
certificates are added.

trigger seeding of SecureRandom
done seeding SecureRandom
%% No cached client session
*** ClientHello, TLSv1
RandomCookie:  GMT: 1259594434 bytes = { 144, 54, 189, 212, 62, 102,
138, 185, 38, 230, 7, 52, 13, 207, 145, 184, 13, 57, 218, 226, 136, 55,
186, 251, 156, 165, 39, 22 }
Session ID:  {}
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA,
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,
SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA,
SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5,
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA,
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA,
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA]
Compression Methods:  { 0 }
***
[write] MD5 and SHA1 hashes:  len = 73
0000: 01 00 00 45 03 01 4B 14   E3 C2 90 36 BD D4 3E 66  ...E..K....6..>f
0010: 8A B9 26 E6 07 34 0D CF   91 B8 0D 39 DA E2 88 37  ..&..4.....9...7
0020: BA FB 9C A5 27 16 00 00   1E 00 04 00 05 00 2F 00  ....'........./.
0030: 33 00 32 00 0A 00 16 00   13 00 09 00 15 00 12 00  3.2.............
0040: 03 00 08 00 14 00 11 01   00                       .........
main, WRITE: TLSv1 Handshake, length = 73
[write] MD5 and SHA1 hashes:  len = 98
0000: 01 03 01 00 39 00 00 00   20 00 00 04 01 00 80 00  ....9... .......
0010: 00 05 00 00 2F 00 00 33   00 00 32 00 00 0A 07 00  ..../..3..2.....
0020: C0 00 00 16 00 00 13 00   00 09 06 00 40 00 00 15  ............@...
0030: 00 00 12 00 00 03 02 00   80 00 00 08 00 00 14 00  ................
0040: 00 11 4B 14 E3 C2 90 36   BD D4 3E 66 8A B9 26 E6  ..K....6..>f..&.
0050: 07 34 0D CF 91 B8 0D 39   DA E2 88 37 BA FB 9C A5  .4.....9...7....
0060: 27 16                                              '.
main, WRITE: SSLv2 client hello message, length = 98
[Raw write]: length = 100
0000: 80 62 01 03 01 00 39 00   00 00 20 00 00 04 01 00  .b....9... .....
0010: 80 00 00 05 00 00 2F 00   00 33 00 00 32 00 00 0A  ....../..3..2...
0020: 07 00 C0 00 00 16 00 00   13 00 00 09 06 00 40 00  ..............@.
0030: 00 15 00 00 12 00 00 03   02 00 80 00 00 08 00 00  ................
0040: 14 00 00 11 4B 14 E3 C2   90 36 BD D4 3E 66 8A B9  ....K....6..>f..
0050: 26 E6 07 34 0D CF 91 B8   0D 39 DA E2 88 37 BA FB  &..4.....9...7..
0060: 9C A5 27 16                                        ..'.
[Raw read]: length = 5
0000: 16 03 01 04 83                                     .....
[Raw read]: length = 1155
0000: 02 00 00 46 03 01 4B 14   E3 C2 F3 E4 D8 B2 48 6E  ...F..K.......Hn
0010: 51 05 23 76 2F 55 5C C5   52 68 83 E6 A4 F4 5D 54  Q.#v/U\.Rh....]T
0020: 25 7E 0B 81 43 5C 20 4B   14 E3 C2 AB 2C B9 71 CE  %...C\ K....,.q.
0030: 7F 91 71 7C 34 6B 54 33   F2 CE 72 58 6C 16 78 DE  ..q.4kT3..rXl.x.
0040: A7 14 AE 3F D5 16 A9 00   04 00 0B 00 04 31 00 04  ...?.........1..
0050: 2E 00 04 2B 30 82 04 27   30 82 03 90 A0 03 02 01  ...+0..'0.......
0060: 02 02 01 00 30 0D 06 09   2A 86 48 86 F7 0D 01 01  ....0...*.H.....
0070: 05 05 00 30 81 C4 31 0B   30 09 06 03 55 04 06 13  ...0..1.0...U...
0080: 02 5A 41 31 10 30 0E 06   03 55 04 08 13 07 47 61  .ZA1.0...U....Ga
0090: 75 74 65 6E 67 31 15 30   13 06 03 55 04 07 13 0C  uteng1.0...U....
00A0: 4A 6F 68 61 6E 6E 65 73   62 75 72 67 31 2E 30 2C  Johannesburg1.0,
00B0: 06 03 55 04 0A 13 25 4F   70 65 6E 20 57 65 62 20  ..U...%Open Web
00C0: 41 70 70 6C 69 63 61 74   69 6F 6E 20 53 65 63 75  Application Secu
00D0: 72 69 74 79 20 50 72 6F   6A 65 63 74 31 12 30 10  rity Project1.0.
00E0: 06 03 55 04 0B 13 09 57   65 62 53 63 61 72 61 62  ..U....WebScarab
00F0: 31 12 30 10 06 03 55 04   03 13 09 57 65 62 53 63  1.0...U....WebSc
0100: 61 72 61 62 31 34 30 32   06 09 2A 86 48 86 F7 0D  arab1402..*.H...
0110: 01 09 01 16 25 6F 77 61   73 70 2D 77 65 62 73 63  ....%owasp-websc
0120: 61 72 61 62 40 6C 69 73   74 73 2E 73 6F 75 72 63  arab@lists.sourc
0130: 65 66 6F 72 67 65 2E 6E   65 74 30 1E 17 0D 30 34  eforge.net0...04
0140: 30 34 30 31 31 32 34 35   35 39 5A 17 0D 31 34 30  0401124559Z..140
0150: 33 33 30 31 32 34 35 35   39 5A 30 81 C4 31 0B 30  330124559Z0..1.0
0160: 09 06 03 55 04 06 13 02   5A 41 31 10 30 0E 06 03  ...U....ZA1.0...
0170: 55 04 08 13 07 47 61 75   74 65 6E 67 31 15 30 13  U....Gauteng1.0.
0180: 06 03 55 04 07 13 0C 4A   6F 68 61 6E 6E 65 73 62  ..U....Johannesb
0190: 75 72 67 31 2E 30 2C 06   03 55 04 0A 13 25 4F 70  urg1.0,..U...%Op
01A0: 65 6E 20 57 65 62 20 41   70 70 6C 69 63 61 74 69  en Web Applicati
01B0: 6F 6E 20 53 65 63 75 72   69 74 79 20 50 72 6F 6A  on Security Proj
01C0: 65 63 74 31 12 30 10 06   03 55 04 0B 13 09 57 65  ect1.0...U....We
01D0: 62 53 63 61 72 61 62 31   12 30 10 06 03 55 04 03  bScarab1.0...U..
01E0: 13 09 57 65 62 53 63 61   72 61 62 31 34 30 32 06  ..WebScarab1402.
01F0: 09 2A 86 48 86 F7 0D 01   09 01 16 25 6F 77 61 73  .*.H.......%owas
0200: 70 2D 77 65 62 73 63 61   72 61 62 40 6C 69 73 74  p-webscarab@list
0210: 73 2E 73 6F 75 72 63 65   66 6F 72 67 65 2E 6E 65  s.sourceforge.ne
0220: 74 30 81 9F 30 0D 06 09   2A 86 48 86 F7 0D 01 01  t0..0...*.H.....
0230: 01 05 00 03 81 8D 00 30   81 89 02 81 81 00 DC 31  .......0.......1
0240: 1C 1A 40 A4 06 BF 67 5E   53 63 84 F6 4B CE 26 F5  ..@...g^Sc..K.&.
0250: B4 4F 8D 26 B2 A7 C0 80   DB 7F 3F AF 33 DF 8A 2F  .O.&......?.3../
0260: F7 E6 D7 B0 37 2A 0B 73   15 7C 7B D4 11 BA 2B 0A  ....7*.s......+.
0270: 54 64 13 8B F5 A9 7F 6D   9E B4 5D 7E 6A 31 BF 2C  Td.....m..].j1.,
0280: DC E6 C1 92 A9 C4 EF 5E   FB 7D B0 CF 8A C6 A7 FB  .......^........
0290: C7 B4 E1 26 62 A3 4C C5   C2 78 29 1F AC 44 C2 98  ...&b.L..x)..D..
02A0: 34 00 08 FC C1 5D D2 22   42 AA E4 1E 7B 03 25 4F  4....]."B.....%O
02B0: FA EA 2D DF 7C C6 1B C2   F6 E3 EB C5 7F FD 02 03  ..-.............
02C0: 01 00 01 A3 82 01 25 30   82 01 21 30 1D 06 03 55  ......%0..!0...U
02D0: 1D 0E 04 16 04 14 C5 2E   DC 77 1B 2D 4B A5 C9 F7  .........w.-K...
02E0: 79 E9 26 38 5C D2 3B C5   46 88 30 81 F1 06 03 55  y.&8\.;.F.0....U
02F0: 1D 23 04 81 E9 30 81 E6   80 14 C5 2E DC 77 1B 2D  .#...0.......w.-
0300: 4B A5 C9 F7 79 E9 26 38   5C D2 3B C5 46 88 A1 81  K...y.&8\.;.F...
0310: CA A4 81 C7 30 81 C4 31   0B 30 09 06 03 55 04 06  ....0..1.0...U..
0320: 13 02 5A 41 31 10 30 0E   06 03 55 04 08 13 07 47  ..ZA1.0...U....G
0330: 61 75 74 65 6E 67 31 15   30 13 06 03 55 04 07 13  auteng1.0...U...
0340: 0C 4A 6F 68 61 6E 6E 65   73 62 75 72 67 31 2E 30  .Johannesburg1.0
0350: 2C 06 03 55 04 0A 13 25   4F 70 65 6E 20 57 65 62  ,..U...%Open Web
0360: 20 41 70 70 6C 69 63 61   74 69 6F 6E 20 53 65 63   Application Sec
0370: 75 72 69 74 79 20 50 72   6F 6A 65 63 74 31 12 30  urity Project1.0
0380: 10 06 03 55 04 0B 13 09   57 65 62 53 63 61 72 61  ...U....WebScara
0390: 62 31 12 30 10 06 03 55   04 03 13 09 57 65 62 53  b1.0...U....WebS
03A0: 63 61 72 61 62 31 34 30   32 06 09 2A 86 48 86 F7  carab1402..*.H..
03B0: 0D 01 09 01 16 25 6F 77   61 73 70 2D 77 65 62 73  .....%owasp-webs
03C0: 63 61 72 61 62 40 6C 69   73 74 73 2E 73 6F 75 72  carab@lists.sour
03D0: 63 65 66 6F 72 67 65 2E   6E 65 74 82 01 00 30 0C  ceforge.net...0.
03E0: 06 03 55 1D 13 04 05 30   03 01 01 FF 30 0D 06 09  ..U....0....0...
03F0: 2A 86 48 86 F7 0D 01 01   05 05 00 03 81 81 00 90  *.H.............
0400: 7B 76 CF 64 A1 45 DF FC   A7 64 F7 1E 7F E9 A7 B0  .v.d.E...d......
0410: EF 3D 3C A2 41 8B 92 9C   BA C4 E6 7B 1F B1 3D 13  .=<.A.........=.
0420: 07 7B F4 A5 1E BC C9 96   9A D2 13 2D D4 7D 8F CB  ...........-....
0430: D9 08 E9 83 E7 90 00 E7   F5 3E 70 3A BD 57 4D AB  .........>p:.WM.
0440: 00 AC E1 CE 85 58 3B 5B   73 56 E8 B6 29 BE 99 E5  .....X;[sV..)...
0450: 91 65 67 B3 20 3A 9F D4   53 A1 D0 43 C6 97 62 BF  .eg. :..S..C..b.
0460: D4 1A 0B 92 45 FC 04 A1   1F 79 2F F2 90 35 DA 80  ....E....y/..5..
0470: DE FE 10 B9 68 B8 70 3E   DB F7 12 01 CB D3 64 0E  ....h.p>......d.
0480: 00 00 00                                           ...
main, READ: TLSv1 Handshake, length = 1155
*** ServerHello, TLSv1
RandomCookie:  GMT: 1259594434 bytes = { 243, 228, 216, 178, 72, 110,
81, 5, 35, 118, 47, 85, 92, 197, 82, 104, 131, 230, 164, 244, 93, 84,
37, 126, 11, 129, 67, 92 }
Session ID:  {75, 20, 227, 194, 171, 44, 185, 113, 206, 127, 145, 113,
124, 52, 107, 84, 51, 242, 206, 114, 88, 108, 22, 120, 222, 167, 20,
174, 63, 213, 22, 169}
Cipher Suite: SSL_RSA_WITH_RC4_128_MD5
Compression Method: 0
***
%% Created:  [Session-1, SSL_RSA_WITH_RC4_128_MD5]
** SSL_RSA_WITH_RC4_128_MD5
[read] MD5 and SHA1 hashes:  len = 74
0000: 02 00 00 46 03 01 4B 14   E3 C2 F3 E4 D8 B2 48 6E  ...F..K.......Hn
0010: 51 05 23 76 2F 55 5C C5   52 68 83 E6 A4 F4 5D 54  Q.#v/U\.Rh....]T
0020: 25 7E 0B 81 43 5C 20 4B   14 E3 C2 AB 2C B9 71 CE  %...C\ K....,.q.
0030: 7F 91 71 7C 34 6B 54 33   F2 CE 72 58 6C 16 78 DE  ..q.4kT3..rXl.x.
0040: A7 14 AE 3F D5 16 A9 00   04 00                    ...?......
*** Certificate chain
chain [0] = [
[
  Version: V3
  Subject: EMAILADDRESS=owasp-webscarab@lists.sourceforge.net,
CN=WebScarab, OU=WebScarab, O=Open Web Application Security Project,
L=Johannesburg, ST=Gauteng, C=ZA
  Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5

  Key:  Sun RSA public key, 1024 bits
  modulus:
154623964938145369797219612839395417706134608433089443549809415871369366723673817041648156759869165956480706191296755342245066633311162904277499876116164772710364652941103434840470861083851860427495958630646686012271912459851197852364216947956958537100938424770176632556183958666972394630932757389391348203517
  public exponent: 65537
  Validity: [From: Thu Apr 01 14:45:59 CEST 2004,
               To: Sun Mar 30 14:45:59 CEST 2014]
  Issuer: EMAILADDRESS=owasp-webscarab@lists.sourceforge.net,
CN=WebScarab, OU=WebScarab, O=Open Web Application Security Project,
L=Johannesburg, ST=Gauteng, C=ZA
  SerialNumber: [    00]

Certificate Extensions: 3
[1]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: C5 2E DC 77 1B 2D 4B A5   C9 F7 79 E9 26 38 5C D2  ...w.-K...y.&8\.
0010: 3B C5 46 88                                        ;.F.
]
]

[2]: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: C5 2E DC 77 1B 2D 4B A5   C9 F7 79 E9 26 38 5C D2  ...w.-K...y.&8\.
0010: 3B C5 46 88                                        ;.F.
]

[EMAILADDRESS=owasp-webscarab@lists.sourceforge.net, CN=WebScarab,
OU=WebScarab, O=Open Web Application Security Project, L=Johannesburg,
ST=Gauteng, C=ZA]
SerialNumber: [    00]
]

[3]: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
  CA:true
  PathLen:2147483647
]

]
  Algorithm: [SHA1withRSA]
  Signature:
0000: 90 7B 76 CF 64 A1 45 DF   FC A7 64 F7 1E 7F E9 A7  ..v.d.E...d.....
0010: B0 EF 3D 3C A2 41 8B 92   9C BA C4 E6 7B 1F B1 3D  ..=<.A.........=
0020: 13 07 7B F4 A5 1E BC C9   96 9A D2 13 2D D4 7D 8F  ............-...
0030: CB D9 08 E9 83 E7 90 00   E7 F5 3E 70 3A BD 57 4D  ..........>p:.WM
0040: AB 00 AC E1 CE 85 58 3B   5B 73 56 E8 B6 29 BE 99  ......X;[sV..)..
0050: E5 91 65 67 B3 20 3A 9F   D4 53 A1 D0 43 C6 97 62  ..eg. :..S..C..b
0060: BF D4 1A 0B 92 45 FC 04   A1 1F 79 2F F2 90 35 DA  .....E....y/..5.
0070: 80 DE FE 10 B9 68 B8 70   3E DB F7 12 01 CB D3 64  .....h.p>......d

]
***
main, SEND TLSv1 ALERT:  fatal, description = certificate_unknown
main, WRITE: TLSv1 Alert, length = 2
[Raw write]: length = 7
0000: 15 03 01 00 02 02 2E                               .......
main, called closeSocket()
main, handling exception: javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to
find valid certification path to requested target
main, IOException in getSession():  javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to
find valid certification path to requested target
Exception in thread "main" javax.net.ssl.SSLPeerUnverifiedException:
peer not authenticated
        at
com.sun.net.ssl.internal.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:352)
        at
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
        at
org.apache.http.conn.ssl.SSLSocketFactory.createSocket(SSLSocketFactory.java:399)
        at
org.apache.http.impl.conn.DefaultClientConnectionOperator.updateSecureConnection(DefaultClientConnectionOperator.java:167)
        at
org.apache.http.impl.conn.AbstractPoolEntry.layerProtocol(AbstractPoolEntry.java:275)
        at
org.apache.http.impl.conn.AbstractPooledConnAdapter.layerProtocol(AbstractPooledConnAdapter.java:122)
        at
org.apache.http.impl.client.DefaultRequestDirector.establishRoute(DefaultRequestDirector.java:668)
        at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:385)
        at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:641)
        at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:576)
        at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:554)
        at httpclienttest.Main.main(Main.java:57)


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

Re: Log creation appears to be a slowdown

2009-11-30T20:48:23Z

Hi Oleg,

Thanks for doing further investigation.

As requested, I have just logged JIRA 
https://issues.apache.org/jira/browse/HTTPCLIENT-895

Cheers,
Tony

Oleg Kalnichevski wrote:
> On Mon, 2009-11-30 at 14:27 +0100, Oleg Kalnichevski wrote:
>   
>> On Sat, 2009-11-28 at 17:01 +0000, Tony Poppleton wrote:
>>     
>>> Hi,
>>>
>>> I have run a JProfiler on my application that uses HttpClient to send 
>>> requests every 10 milliseconds.  One interesting part of the results is 
>>> that the Log creation is actually consuming about 5% of the time, which 
>>> is significant considering I am trying to squeeze the most performance 
>>> out.  For example:
>>>
>>>     public class ClientParamsStack extends AbstractHttpParams {
>>>         private final Log log = LogFactory.getLog(getClass());
>>>
>>> I have always used static loggers myself, which avoid this problem, so I 
>>> did a tiny bit of research 
>>> (http://wiki.apache.org/jakarta-commons/Logging/StaticLog) and 
>>> apparently static isn't always the right choice.
>>>
>>>
>>> Is there anything I can do to prevent the log creation from being a 
>>> slowdown, short of checking out the source tree and creating my own 
>>> custom patch?
>>>
>>> I haven't investigated fully yet, but ClientParamsStack class seems to 
>>> be the main culprit, so is there any way I can set it to use my own 
>>> custom implementation of this?
>>>
>>>       
>> Tony,
>>
>> If log creation does indeed have such an adverse effect on performance,
>> I would very much rather prefer to fix the problem in the library
>> itself. If you are reasonably sure performance can be improved by
>> eliminating certain log instances, please remove them and submit a patch
>> for inclusion into the official code base.
>>
>> Cheers
>>
>> Oleg  
>>
>>     
>
> Hhhm. I get good 5 to 7% performance improvement by eliminating Log
> instances in ClientParamsStack and DefaultHttpRequestDirector classes. I
> never imagined the performance penalty of the Log lookup operation was
> so significant. 
>
> Tony,
>
> Could you please open an issue in JIRA for this problem?
>
> Oleg
>
>
>   
>>> Many thanks,
>>> Tony
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>>>
>>>       
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>>
>>     
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
> ---------------------------------------------------------------------------------------
> Orange vous informe que cet  e-mail a ete controle par l'anti-virus mail. 
> Aucun virus connu a ce jour par nos services n'a ete detecte.
>
>
>
>

Re: Log creation appears to be a slowdown

2009-11-30T17:22:22Z

On Mon, 2009-11-30 at 14:27 +0100, Oleg Kalnichevski wrote:
> On Sat, 2009-11-28 at 17:01 +0000, Tony Poppleton wrote:
> > Hi,
> > 
> > I have run a JProfiler on my application that uses HttpClient to send 
> > requests every 10 milliseconds.  One interesting part of the results is 
> > that the Log creation is actually consuming about 5% of the time, which 
> > is significant considering I am trying to squeeze the most performance 
> > out.  For example:
> > 
> >     public class ClientParamsStack extends AbstractHttpParams {
> >         private final Log log = LogFactory.getLog(getClass());
> > 
> > I have always used static loggers myself, which avoid this problem, so I 
> > did a tiny bit of research 
> > (http://wiki.apache.org/jakarta-commons/Logging/StaticLog) and 
> > apparently static isn't always the right choice.
> > 
> >
> > Is there anything I can do to prevent the log creation from being a 
> > slowdown, short of checking out the source tree and creating my own 
> > custom patch?
> > 
> > I haven't investigated fully yet, but ClientParamsStack class seems to 
> > be the main culprit, so is there any way I can set it to use my own 
> > custom implementation of this?
> > 
> 
> Tony,
> 
> If log creation does indeed have such an adverse effect on performance,
> I would very much rather prefer to fix the problem in the library
> itself. If you are reasonably sure performance can be improved by
> eliminating certain log instances, please remove them and submit a patch
> for inclusion into the official code base.
> 
> Cheers
> 
> Oleg  
> 

Hhhm. I get good 5 to 7% performance improvement by eliminating Log
instances in ClientParamsStack and DefaultHttpRequestDirector classes. I
never imagined the performance penalty of the Log lookup operation was
so significant. 

Tony,

Could you please open an issue in JIRA for this problem?

Oleg


> 
> > Many thanks,
> > Tony
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> > 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

Re: implementation of a custom HttpRoutePlanner - how to choose the HttpRoute attributes (secure, tunnel type, and layer type)?

2009-11-30T14:43:08Z

On Mon, 2009-11-30 at 15:17 +0100, Stefan Wachter wrote:
> Hi Oleg,
> 
> I do not understand your comment: "Which makes perfect sense". You said
> that proxies are usually accessed by http (and not https). You said that
> a route must be marked secure in order to have secure cookies to be
> sent. Now, if I try to use HttpClient with a proxy, connect to this
> proxy using http and mark the route to be secure then I get the
> IllegalStateException.
> 
> Cheers,
> --Stefan
> 

I am sorry but this is going to be my last try.

Proxied HTTPS route takes two hops: (1) initial connection is
established by opening a tunnel with HTTP CONNECT (HTTP and not HTTPS);
(2) once the tunnel is established SSL protocol is layered over the
plain connection. Therefore the route must be both TunnelType.TUNNELLED
and LayerType.LAYERED and can be marked secure. 

Oleg

> 
> Am 30.11.2009 14:38, schrieb Oleg Kalnichevski:
> > On Mon, 2009-11-30 at 10:42 +0100, Stefan Wachter wrote:
> >   
> >> Hi Oleg,
> >>
> >> I implemented a small test case that demonstrates my problem. The
> >> program uses a single proxy that is accessed by http (I use WebScarab).
> >> When the program runs then I get the already mentioned illegal state
> >> exception:
> >>
> >>     
> > Which makes perfect sense.
> >
> >   
> >> planned = HttpRoute[{s}->http://localhost:8008->https://www.gmx.net]
> >> current = HttpRoute[{}->http://localhost:8008->https://www.gmx.net]
> >>         at
> >> org.apache.http.impl.client.DefaultRequestDirector.establishRoute(DefaultRequestDirector.java:672)
> >>         at
> >> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:385)
> >>         at
> >> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:641)
> >>         at
> >> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:576)
> >>         at
> >> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:554)
> >>         at httpclienttest.Main.main(Main.java:68)
> >>
> >> When I change the boolean tunneledAndLayered from false to true then I
> >> get a SSLPeerUnverifiedException:
> >>
> >>
> >> Exception in thread "main" javax.net.ssl.SSLPeerUnverifiedException:
> >> peer not authenticated
> >>         at
> >> com.sun.net.ssl.internal.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:352)
> >>         at
> >> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
> >>         at
> >> org.apache.http.conn.ssl.SSLSocketFactory.createSocket(SSLSocketFactory.java:399)
> >>         at
> >> org.apache.http.impl.conn.DefaultClientConnectionOperator.updateSecureConnection(DefaultClientConnectionOperator.java:167)
> >>         at
> >> org.apache.http.impl.conn.AbstractPoolEntry.layerProtocol(AbstractPoolEntry.java:275)
> >>         at
> >> org.apache.http.impl.conn.AbstractPooledConnAdapter.layerProtocol(AbstractPooledConnAdapter.java:122)
> >>         at
> >> org.apache.http.impl.client.DefaultRequestDirector.establishRoute(DefaultRequestDirector.java:668)
> >>         at
> >> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:385)
> >>         at
> >> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:641)
> >>         at
> >> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:576)
> >>         at
> >> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:554)
> >>         at httpclienttest.Main.main(Main.java:57)
> >>
> >> You said that this exception is caused because the SSL context of the
> >> application is not configured correctly. Unfortunately I do not how the
> >> SSL context is configured. Can you please give me a hint.
> >>
> >>     
> > The official Java SSL tutorial is your best friend
> >
> > Oleg
> >
> >   
> >> Best regards,
> >> --Stefan
> >>
> >>
> >>
> >> package httpclienttest;
> >>
> >> import org.apache.http.HttpException;
> >> import org.apache.http.HttpHost;
> >> import org.apache.http.HttpRequest;
> >> import org.apache.http.client.methods.HttpGet;
> >> import org.apache.http.client.methods.HttpUriRequest;
> >> import org.apache.http.conn.ClientConnectionManager;
> >> import org.apache.http.conn.routing.HttpRoute;
> >> import org.apache.http.conn.routing.HttpRoutePlanner;
> >> import org.apache.http.conn.routing.RouteInfo.LayerType;
> >> import org.apache.http.conn.routing.RouteInfo.TunnelType;
> >> import org.apache.http.conn.scheme.PlainSocketFactory;
> >> import org.apache.http.conn.scheme.Scheme;
> >> import org.apache.http.conn.scheme.SchemeRegistry;
> >> import org.apache.http.conn.ssl.SSLSocketFactory;
> >> import org.apache.http.impl.client.DefaultHttpClient;
> >> import org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager;
> >> import org.apache.http.params.BasicHttpParams;
> >> import org.apache.http.params.HttpParams;
> >> import org.apache.http.protocol.HttpContext;
> >>
> >> public class Main {
> >>
> >>   public static void main(String[] args) throws Exception {
> >>     HttpParams httpParams = new BasicHttpParams();
> >>
> >>     SchemeRegistry schemeRegistry = new SchemeRegistry();
> >>     schemeRegistry.register(new Scheme("http",
> >> PlainSocketFactory.getSocketFactory(), 80));
> >>     schemeRegistry.register(new Scheme("https",
> >> SSLSocketFactory.getSocketFactory(), 443));
> >>
> >>     ClientConnectionManager connectionManager = new
> >> ThreadSafeClientConnManager(httpParams, schemeRegistry);
> >>
> >>     DefaultHttpClient httpClient = new
> >> DefaultHttpClient(connectionManager, httpParams);
> >>
> >>     HttpRoutePlanner routePlanner = new HttpRoutePlanner() {
> >>
> >>       public HttpRoute determineRoute(HttpHost aTarget, HttpRequest
> >> aRequest, HttpContext aContext) throws HttpException {
> >>
> >>         HttpHost[] proxies = new HttpHost[1];
> >>         proxies[0] = new HttpHost("localhost", 8008, "http");
> >>         boolean isSecure = true;
> >>
> >>         boolean tunneledAndLayered = false;
> >>         TunnelType tunnelType = tunneledAndLayered ?
> >> TunnelType.TUNNELLED : TunnelType.PLAIN;
> >>         LayerType layerType = tunneledAndLayered ? LayerType.LAYERED :
> >> LayerType.PLAIN;
> >>
> >>         return new HttpRoute(aTarget, null, proxies, isSecure,
> >> tunnelType, layerType);
> >>
> >>       }
> >>
> >>     };
> >>
> >>     httpClient.setRoutePlanner(routePlanner);
> >>
> >>     HttpUriRequest request = new HttpGet("https://www.gmx.net");
> >>     httpClient.execute(request);
> >>
> >>   }
> >> }
> >>
> >>
> >> Am 27.11.2009 22:29, schrieb Oleg Kalnichevski:
> >>     
> >>> Stefan Wachter wrote:
> >>>       
> >>>> Hi Oleg,
> >>>>
> >>>> your proposal "you need to mark the route as secure but the initial
> >>>> connection to the proxy should be made via HTTP" does not work. If the
> >>>> route is planned in such a way then an IllegalStateException is raised
> >>>> (as I mentioned in my last post). This is caused by the logic
> >>>> implemented in HttpClient that a secure route can not use an insecure
> >>>> connection.
> >>>>         
> >>> That does not seem to make any sense to me but I did not write HTTP
> >>> route planning code. The default logic seems pretty straightforward.
> >>>
> >>> http://hc.apache.org/httpcomponents-client/httpclient/xref/org/apache/http/impl/conn/DefaultHttpRoutePlanner.html#111
> >>>
> >>>
> >>> Please double-check your code and if you are convinced this is a bug
> >>> in HttpClient please try to reproduce the problem with a test case.
> >>>
> >>> Oleg
> >>>
> >>>       
> >>>> Can you please give me a hint how the SSL context of the application
can
> >>>> be configured correctly?
> >>>>
> >>>> Why I want to implement a custom route planner: I have integrated
> >>>> HttpClient into an (web) application framework to allow easy access
to
> >>>> the HTTP protocol. I do not like the standard jvm proxy mechanism
> >>>> because it is configured virtual machine wide and the configuration
must
> >>>> be done on the command line or by setting system properties. Using a
> >>>> configurable custom route planner just would better fit into the overall
> >>>> structure. I did not expect that implementing a custom route planner
> >>>> would be so difficult. In addition, I like the possibilities for
> >>>> connection pooling that HttpClient offers. I thought that in order to
> >>>> configure the pooling for routes it is best to determine the by myself.
> >>>> Otherwise I must have a close look at the routes that are returned by
> >>>> the "ProxySelectorRoutePlanner".
> >>>>
> >>>> Thank you for your help,
> >>>>
> >>>> --Stefan
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Am 27.11.2009 17:17, schrieb Oleg Kalnichevski:
> >>>>         
> >>>>> Stefan Wachter wrote:
> >>>>>           
> >>>>>> Hi Oleg,
> >>>>>>
> >>>>>> I still struggle with the implementation of my HttpRoutePlanner.
> >>>>>>
> >>>>>> I try to establish an HTTPS connection to a target host via
a
> >>>>>> proxy. You
> >>>>>> said that "usually the tunnel to the proxy is established using
plain
> >>>>>> HTTP". When I try to return a route where the first hop (the
hop to
> >>>>>> the
> >>>>>> proxy) is using HTTP then the secure flag of the route must
not be
> >>>>>> "true". If you try then the following exception is raised:
> >>>>>>
> >>>>>> java.lang.IllegalStateException: Unable to establish route.
> >>>>>> planned = HttpRoute[{s}->http://localhost:8008->https://www.gmx.net]
> >>>>>> current = HttpRoute[{}->http://localhost:8008->https://www.gmx.net]
> >>>>>>
> >>>>>> I tracked the reason down and found that the isSecure method
of the
> >>>>>> PlainSocketFactory always returns false. This means that if
the
> >>>>>> proxy is
> >>>>>> accessed using http then the route must not be flagged to be
> >>>>>> secure. You
> >>>>>> said that if a route is flagged unsecure then "this will prevent
> >>>>>> HttpClient from sending cookies marked as secure".
> >>>>>>
> >>>>>> To summarize: If I want to contact a target host via a proxy
by https
> >>>>>> and want to have cookies that are marked to be secure to be
sent
> >>>>>> then I
> >>>>>> have to use https to contact the proxy and mark the route as
being
> >>>>>> secure. Right?
> >>>>>>             
> >>>>> Yes, you need to mark the route as secure but the initial connection
> >>>>> to the proxy should be made via HTTP. I have not come across an
HTTP
> >>>>> proxy that supported CONNECT method via HTTPS.
> >>>>>
> >>>>>           
> >>>>>> In your last response you wrote, that for proxied https connections
> >>>>>> TunnelType.TUNELLED and LayerType.LAYERED should be choosen.
When I
> >>>>>> return a route that uses https to access the proxy and the target
> >>>>>> host,
> >>>>>> that has its secure flag set to true and that is tunneled and
> >>>>>> layered, I
> >>>>>> get the following exception:
> >>>>>>
> >>>>>>             
> >>>>> This problem has nothing to do with the route computation or even
> >>>>> HttpClient at all. The SSL context used by your application has
not
> >>>>> been configured correctly.
> >>>>>
> >>>>>           
> >>>>>> javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
> >>>>>>         at
> >>>>>> com.sun.net.ssl.internal.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:352)
> >>>>>>
> >>>>>>
> >>>>>>         at
> >>>>>> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
> >>>>>>
> >>>>>>
> >>>>>>         at
> >>>>>> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:339)
> >>>>>>
> >>>>>>
> >>>>>>         at
> >>>>>> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:123)
> >>>>>>
> >>>>>>
> >>>>>>         at
> >>>>>> org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:147)
> >>>>>>
> >>>>>>
> >>>>>>         at
> >>>>>> org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:101)
> >>>>>>
> >>>>>>
> >>>>>>         at
> >>>>>> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:381)
> >>>>>>
> >>>>>>
> >>>>>>         at
> >>>>>> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:641)
> >>>>>>
> >>>>>>
> >>>>>>         at
> >>>>>> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:576)
> >>>>>>
> >>>>>>
> >>>>>>         at
> >>>>>> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:554)
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> What is going wrong here? Does it mean that the proxy host needs
to
> >>>>>> have
> >>>>>> a certifacate that is signed by a trusted certifaction authority?
> >>>>>>
> >>>>>>             
> >>>>> I have no idea about expectations of your proxy host. Did CONNECT
> >>>>> method succeed?
> >>>>>
> >>>>>           
> >>>>>> Next try: If I choose a route that uses http to access the proxy
host
> >>>>>> and https to access the target host and use TunnelType.PLAIN
and
> >>>>>> LayerType.PLAIN then the route works. 
> >>>>>>             
> >>>>> I suspect SSL/TLS is not being used in this case.
> >>>>>
> >>>>> The route should be marked as TunnelType.TUNELLED and
> >>>>> LayerType.LAYERED and the SSL context of your application must be
set
> >>>>> up correctly.
> >>>>>
> >>>>> Why do you need a custom route planner in the first place?
> >>>>>
> >>>>> Oleg
> >>>>>
> >>>>>
> >>>>> Yet, this route can not be marked
> >>>>>           
> >>>>>> to be secure. This means that secure cookies are not sent!
> >>>>>>
> >>>>>> Thanks for you patience and help,
> >>>>>>
> >>>>>> --Stefan
> >>>>>>
> >>>>>>             
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> >>>>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >>>>>
> >>>>>           
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> >>>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >>>>
> >>>>         
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> >>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >>>
> >>>       
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> >> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >>
> >>     
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
> >   
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

Re: implementation of a custom HttpRoutePlanner - how to choose the HttpRoute attributes (secure, tunnel type, and layer type)?

2009-11-30T14:17:41Z

Hi Oleg,

I do not understand your comment: "Which makes perfect sense". You said
that proxies are usually accessed by http (and not https). You said that
a route must be marked secure in order to have secure cookies to be
sent. Now, if I try to use HttpClient with a proxy, connect to this
proxy using http and mark the route to be secure then I get the
IllegalStateException.

Cheers,
--Stefan


Am 30.11.2009 14:38, schrieb Oleg Kalnichevski:
> On Mon, 2009-11-30 at 10:42 +0100, Stefan Wachter wrote:
>   
>> Hi Oleg,
>>
>> I implemented a small test case that demonstrates my problem. The
>> program uses a single proxy that is accessed by http (I use WebScarab).
>> When the program runs then I get the already mentioned illegal state
>> exception:
>>
>>     
> Which makes perfect sense.
>
>   
>> planned = HttpRoute[{s}->http://localhost:8008->https://www.gmx.net]
>> current = HttpRoute[{}->http://localhost:8008->https://www.gmx.net]
>>         at
>> org.apache.http.impl.client.DefaultRequestDirector.establishRoute(DefaultRequestDirector.java:672)
>>         at
>> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:385)
>>         at
>> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:641)
>>         at
>> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:576)
>>         at
>> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:554)
>>         at httpclienttest.Main.main(Main.java:68)
>>
>> When I change the boolean tunneledAndLayered from false to true then I
>> get a SSLPeerUnverifiedException:
>>
>>
>> Exception in thread "main" javax.net.ssl.SSLPeerUnverifiedException:
>> peer not authenticated
>>         at
>> com.sun.net.ssl.internal.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:352)
>>         at
>> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
>>         at
>> org.apache.http.conn.ssl.SSLSocketFactory.createSocket(SSLSocketFactory.java:399)
>>         at
>> org.apache.http.impl.conn.DefaultClientConnectionOperator.updateSecureConnection(DefaultClientConnectionOperator.java:167)
>>         at
>> org.apache.http.impl.conn.AbstractPoolEntry.layerProtocol(AbstractPoolEntry.java:275)
>>         at
>> org.apache.http.impl.conn.AbstractPooledConnAdapter.layerProtocol(AbstractPooledConnAdapter.java:122)
>>         at
>> org.apache.http.impl.client.DefaultRequestDirector.establishRoute(DefaultRequestDirector.java:668)
>>         at
>> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:385)
>>         at
>> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:641)
>>         at
>> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:576)
>>         at
>> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:554)
>>         at httpclienttest.Main.main(Main.java:57)
>>
>> You said that this exception is caused because the SSL context of the
>> application is not configured correctly. Unfortunately I do not how the
>> SSL context is configured. Can you please give me a hint.
>>
>>     
> The official Java SSL tutorial is your best friend
>
> Oleg
>
>   
>> Best regards,
>> --Stefan
>>
>>
>>
>> package httpclienttest;
>>
>> import org.apache.http.HttpException;
>> import org.apache.http.HttpHost;
>> import org.apache.http.HttpRequest;
>> import org.apache.http.client.methods.HttpGet;
>> import org.apache.http.client.methods.HttpUriRequest;
>> import org.apache.http.conn.ClientConnectionManager;
>> import org.apache.http.conn.routing.HttpRoute;
>> import org.apache.http.conn.routing.HttpRoutePlanner;
>> import org.apache.http.conn.routing.RouteInfo.LayerType;
>> import org.apache.http.conn.routing.RouteInfo.TunnelType;
>> import org.apache.http.conn.scheme.PlainSocketFactory;
>> import org.apache.http.conn.scheme.Scheme;
>> import org.apache.http.conn.scheme.SchemeRegistry;
>> import org.apache.http.conn.ssl.SSLSocketFactory;
>> import org.apache.http.impl.client.DefaultHttpClient;
>> import org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager;
>> import org.apache.http.params.BasicHttpParams;
>> import org.apache.http.params.HttpParams;
>> import org.apache.http.protocol.HttpContext;
>>
>> public class Main {
>>
>>   public static void main(String[] args) throws Exception {
>>     HttpParams httpParams = new BasicHttpParams();
>>
>>     SchemeRegistry schemeRegistry = new SchemeRegistry();
>>     schemeRegistry.register(new Scheme("http",
>> PlainSocketFactory.getSocketFactory(), 80));
>>     schemeRegistry.register(new Scheme("https",
>> SSLSocketFactory.getSocketFactory(), 443));
>>
>>     ClientConnectionManager connectionManager = new
>> ThreadSafeClientConnManager(httpParams, schemeRegistry);
>>
>>     DefaultHttpClient httpClient = new
>> DefaultHttpClient(connectionManager, httpParams);
>>
>>     HttpRoutePlanner routePlanner = new HttpRoutePlanner() {
>>
>>       public HttpRoute determineRoute(HttpHost aTarget, HttpRequest
>> aRequest, HttpContext aContext) throws HttpException {
>>
>>         HttpHost[] proxies = new HttpHost[1];
>>         proxies[0] = new HttpHost("localhost", 8008, "http");
>>         boolean isSecure = true;
>>
>>         boolean tunneledAndLayered = false;
>>         TunnelType tunnelType = tunneledAndLayered ?
>> TunnelType.TUNNELLED : TunnelType.PLAIN;
>>         LayerType layerType = tunneledAndLayered ? LayerType.LAYERED :
>> LayerType.PLAIN;
>>
>>         return new HttpRoute(aTarget, null, proxies, isSecure,
>> tunnelType, layerType);
>>
>>       }
>>
>>     };
>>
>>     httpClient.setRoutePlanner(routePlanner);
>>
>>     HttpUriRequest request = new HttpGet("https://www.gmx.net");
>>     httpClient.execute(request);
>>
>>   }
>> }
>>
>>
>> Am 27.11.2009 22:29, schrieb Oleg Kalnichevski:
>>     
>>> Stefan Wachter wrote:
>>>       
>>>> Hi Oleg,
>>>>
>>>> your proposal "you need to mark the route as secure but the initial
>>>> connection to the proxy should be made via HTTP" does not work. If the
>>>> route is planned in such a way then an IllegalStateException is raised
>>>> (as I mentioned in my last post). This is caused by the logic
>>>> implemented in HttpClient that a secure route can not use an insecure
>>>> connection.
>>>>         
>>> That does not seem to make any sense to me but I did not write HTTP
>>> route planning code. The default logic seems pretty straightforward.
>>>
>>> http://hc.apache.org/httpcomponents-client/httpclient/xref/org/apache/http/impl/conn/DefaultHttpRoutePlanner.html#111
>>>
>>>
>>> Please double-check your code and if you are convinced this is a bug
>>> in HttpClient please try to reproduce the problem with a test case.
>>>
>>> Oleg
>>>
>>>       
>>>> Can you please give me a hint how the SSL context of the application can
>>>> be configured correctly?
>>>>
>>>> Why I want to implement a custom route planner: I have integrated
>>>> HttpClient into an (web) application framework to allow easy access to
>>>> the HTTP protocol. I do not like the standard jvm proxy mechanism
>>>> because it is configured virtual machine wide and the configuration must
>>>> be done on the command line or by setting system properties. Using a
>>>> configurable custom route planner just would better fit into the overall
>>>> structure. I did not expect that implementing a custom route planner
>>>> would be so difficult. In addition, I like the possibilities for
>>>> connection pooling that HttpClient offers. I thought that in order to
>>>> configure the pooling for routes it is best to determine the by myself.
>>>> Otherwise I must have a close look at the routes that are returned by
>>>> the "ProxySelectorRoutePlanner".
>>>>
>>>> Thank you for your help,
>>>>
>>>> --Stefan
>>>>
>>>>
>>>>
>>>>
>>>> Am 27.11.2009 17:17, schrieb Oleg Kalnichevski:
>>>>         
>>>>> Stefan Wachter wrote:
>>>>>           
>>>>>> Hi Oleg,
>>>>>>
>>>>>> I still struggle with the implementation of my HttpRoutePlanner.
>>>>>>
>>>>>> I try to establish an HTTPS connection to a target host via a
>>>>>> proxy. You
>>>>>> said that "usually the tunnel to the proxy is established using plain
>>>>>> HTTP". When I try to return a route where the first hop (the hop
to
>>>>>> the
>>>>>> proxy) is using HTTP then the secure flag of the route must not be
>>>>>> "true". If you try then the following exception is raised:
>>>>>>
>>>>>> java.lang.IllegalStateException: Unable to establish route.
>>>>>> planned = HttpRoute[{s}->http://localhost:8008->https://www.gmx.net]
>>>>>> current = HttpRoute[{}->http://localhost:8008->https://www.gmx.net]
>>>>>>
>>>>>> I tracked the reason down and found that the isSecure method of the
>>>>>> PlainSocketFactory always returns false. This means that if the
>>>>>> proxy is
>>>>>> accessed using http then the route must not be flagged to be
>>>>>> secure. You
>>>>>> said that if a route is flagged unsecure then "this will prevent
>>>>>> HttpClient from sending cookies marked as secure".
>>>>>>
>>>>>> To summarize: If I want to contact a target host via a proxy by https
>>>>>> and want to have cookies that are marked to be secure to be sent
>>>>>> then I
>>>>>> have to use https to contact the proxy and mark the route as being
>>>>>> secure. Right?
>>>>>>             
>>>>> Yes, you need to mark the route as secure but the initial connection
>>>>> to the proxy should be made via HTTP. I have not come across an HTTP
>>>>> proxy that supported CONNECT method via HTTPS.
>>>>>
>>>>>           
>>>>>> In your last response you wrote, that for proxied https connections
>>>>>> TunnelType.TUNELLED and LayerType.LAYERED should be choosen. When
I
>>>>>> return a route that uses https to access the proxy and the target
>>>>>> host,
>>>>>> that has its secure flag set to true and that is tunneled and
>>>>>> layered, I
>>>>>> get the following exception:
>>>>>>
>>>>>>             
>>>>> This problem has nothing to do with the route computation or even
>>>>> HttpClient at all. The SSL context used by your application has not
>>>>> been configured correctly.
>>>>>
>>>>>           
>>>>>> javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
>>>>>>         at
>>>>>> com.sun.net.ssl.internal.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:352)
>>>>>>
>>>>>>
>>>>>>         at
>>>>>> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
>>>>>>
>>>>>>
>>>>>>         at
>>>>>> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:339)
>>>>>>
>>>>>>
>>>>>>         at
>>>>>> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:123)
>>>>>>
>>>>>>
>>>>>>         at
>>>>>> org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:147)
>>>>>>
>>>>>>
>>>>>>         at
>>>>>> org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:101)
>>>>>>
>>>>>>
>>>>>>         at
>>>>>> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:381)
>>>>>>
>>>>>>
>>>>>>         at
>>>>>> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:641)
>>>>>>
>>>>>>
>>>>>>         at
>>>>>> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:576)
>>>>>>
>>>>>>
>>>>>>         at
>>>>>> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:554)
>>>>>>
>>>>>>
>>>>>>
>>>>>> What is going wrong here? Does it mean that the proxy host needs
to
>>>>>> have
>>>>>> a certifacate that is signed by a trusted certifaction authority?
>>>>>>
>>>>>>             
>>>>> I have no idea about expectations of your proxy host. Did CONNECT
>>>>> method succeed?
>>>>>
>>>>>           
>>>>>> Next try: If I choose a route that uses http to access the proxy
host
>>>>>> and https to access the target host and use TunnelType.PLAIN and
>>>>>> LayerType.PLAIN then the route works. 
>>>>>>             
>>>>> I suspect SSL/TLS is not being used in this case.
>>>>>
>>>>> The route should be marked as TunnelType.TUNELLED and
>>>>> LayerType.LAYERED and the SSL context of your application must be set
>>>>> up correctly.
>>>>>
>>>>> Why do you need a custom route planner in the first place?
>>>>>
>>>>> Oleg
>>>>>
>>>>>
>>>>> Yet, this route can not be marked
>>>>>           
>>>>>> to be secure. This means that secure cookies are not sent!
>>>>>>
>>>>>> Thanks for you patience and help,
>>>>>>
>>>>>> --Stefan
>>>>>>
>>>>>>             
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>>>>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>>>>>
>>>>>           
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>>>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>>>>
>>>>         
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>>>
>>>       
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>>
>>     
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

Re: implementation of a custom HttpRoutePlanner - how to choose the HttpRoute attributes (secure, tunnel type, and layer type)?

2009-11-30T13:38:23Z

On Mon, 2009-11-30 at 10:42 +0100, Stefan Wachter wrote:
> Hi Oleg,
> 
> I implemented a small test case that demonstrates my problem. The
> program uses a single proxy that is accessed by http (I use WebScarab).
> When the program runs then I get the already mentioned illegal state
> exception:
> 

Which makes perfect sense.

> planned = HttpRoute[{s}->http://localhost:8008->https://www.gmx.net]
> current = HttpRoute[{}->http://localhost:8008->https://www.gmx.net]
>         at
> org.apache.http.impl.client.DefaultRequestDirector.establishRoute(DefaultRequestDirector.java:672)
>         at
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:385)
>         at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:641)
>         at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:576)
>         at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:554)
>         at httpclienttest.Main.main(Main.java:68)
> 
> When I change the boolean tunneledAndLayered from false to true then I
> get a SSLPeerUnverifiedException:
> 
>
> Exception in thread "main" javax.net.ssl.SSLPeerUnverifiedException:
> peer not authenticated
>         at
> com.sun.net.ssl.internal.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:352)
>         at
> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
>         at
> org.apache.http.conn.ssl.SSLSocketFactory.createSocket(SSLSocketFactory.java:399)
>         at
> org.apache.http.impl.conn.DefaultClientConnectionOperator.updateSecureConnection(DefaultClientConnectionOperator.java:167)
>         at
> org.apache.http.impl.conn.AbstractPoolEntry.layerProtocol(AbstractPoolEntry.java:275)
>         at
> org.apache.http.impl.conn.AbstractPooledConnAdapter.layerProtocol(AbstractPooledConnAdapter.java:122)
>         at
> org.apache.http.impl.client.DefaultRequestDirector.establishRoute(DefaultRequestDirector.java:668)
>         at
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:385)
>         at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:641)
>         at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:576)
>         at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:554)
>         at httpclienttest.Main.main(Main.java:57)
> 
> You said that this exception is caused because the SSL context of the
> application is not configured correctly. Unfortunately I do not how the
> SSL context is configured. Can you please give me a hint.
> 

The official Java SSL tutorial is your best friend

Oleg

> Best regards,
> --Stefan
> 
> 
> 
> package httpclienttest;
> 
> import org.apache.http.HttpException;
> import org.apache.http.HttpHost;
> import org.apache.http.HttpRequest;
> import org.apache.http.client.methods.HttpGet;
> import org.apache.http.client.methods.HttpUriRequest;
> import org.apache.http.conn.ClientConnectionManager;
> import org.apache.http.conn.routing.HttpRoute;
> import org.apache.http.conn.routing.HttpRoutePlanner;
> import org.apache.http.conn.routing.RouteInfo.LayerType;
> import org.apache.http.conn.routing.RouteInfo.TunnelType;
> import org.apache.http.conn.scheme.PlainSocketFactory;
> import org.apache.http.conn.scheme.Scheme;
> import org.apache.http.conn.scheme.SchemeRegistry;
> import org.apache.http.conn.ssl.SSLSocketFactory;
> import org.apache.http.impl.client.DefaultHttpClient;
> import org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager;
> import org.apache.http.params.BasicHttpParams;
> import org.apache.http.params.HttpParams;
> import org.apache.http.protocol.HttpContext;
> 
> public class Main {
> 
>   public static void main(String[] args) throws Exception {
>     HttpParams httpParams = new BasicHttpParams();
> 
>     SchemeRegistry schemeRegistry = new SchemeRegistry();
>     schemeRegistry.register(new Scheme("http",
> PlainSocketFactory.getSocketFactory(), 80));
>     schemeRegistry.register(new Scheme("https",
> SSLSocketFactory.getSocketFactory(), 443));
> 
>     ClientConnectionManager connectionManager = new
> ThreadSafeClientConnManager(httpParams, schemeRegistry);
> 
>     DefaultHttpClient httpClient = new
> DefaultHttpClient(connectionManager, httpParams);
> 
>     HttpRoutePlanner routePlanner = new HttpRoutePlanner() {
> 
>       public HttpRoute determineRoute(HttpHost aTarget, HttpRequest
> aRequest, HttpContext aContext) throws HttpException {
> 
>         HttpHost[] proxies = new HttpHost[1];
>         proxies[0] = new HttpHost("localhost", 8008, "http");
>         boolean isSecure = true;
> 
>         boolean tunneledAndLayered = false;
>         TunnelType tunnelType = tunneledAndLayered ?
> TunnelType.TUNNELLED : TunnelType.PLAIN;
>         LayerType layerType = tunneledAndLayered ? LayerType.LAYERED :
> LayerType.PLAIN;
> 
>         return new HttpRoute(aTarget, null, proxies, isSecure,
> tunnelType, layerType);
> 
>       }
> 
>     };
> 
>     httpClient.setRoutePlanner(routePlanner);
> 
>     HttpUriRequest request = new HttpGet("https://www.gmx.net");
>     httpClient.execute(request);
> 
>   }
> }
> 
> 
> Am 27.11.2009 22:29, schrieb Oleg Kalnichevski:
> > Stefan Wachter wrote:
> >> Hi Oleg,
> >>
> >> your proposal "you need to mark the route as secure but the initial
> >> connection to the proxy should be made via HTTP" does not work. If the
> >> route is planned in such a way then an IllegalStateException is raised
> >> (as I mentioned in my last post). This is caused by the logic
> >> implemented in HttpClient that a secure route can not use an insecure
> >> connection.
> >
> > That does not seem to make any sense to me but I did not write HTTP
> > route planning code. The default logic seems pretty straightforward.
> >
> > http://hc.apache.org/httpcomponents-client/httpclient/xref/org/apache/http/impl/conn/DefaultHttpRoutePlanner.html#111
> >
> >
> > Please double-check your code and if you are convinced this is a bug
> > in HttpClient please try to reproduce the problem with a test case.
> >
> > Oleg
> >
> >>
> >> Can you please give me a hint how the SSL context of the application can
> >> be configured correctly?
> >>
> >> Why I want to implement a custom route planner: I have integrated
> >> HttpClient into an (web) application framework to allow easy access to
> >> the HTTP protocol. I do not like the standard jvm proxy mechanism
> >> because it is configured virtual machine wide and the configuration must
> >> be done on the command line or by setting system properties. Using a
> >> configurable custom route planner just would better fit into the overall
> >> structure. I did not expect that implementing a custom route planner
> >> would be so difficult. In addition, I like the possibilities for
> >> connection pooling that HttpClient offers. I thought that in order to
> >> configure the pooling for routes it is best to determine the by myself.
> >> Otherwise I must have a close look at the routes that are returned by
> >> the "ProxySelectorRoutePlanner".
> >>
> >> Thank you for your help,
> >>
> >> --Stefan
> >>
> >>
> >>
> >>
> >> Am 27.11.2009 17:17, schrieb Oleg Kalnichevski:
> >>> Stefan Wachter wrote:
> >>>> Hi Oleg,
> >>>>
> >>>> I still struggle with the implementation of my HttpRoutePlanner.
> >>>>
> >>>> I try to establish an HTTPS connection to a target host via a
> >>>> proxy. You
> >>>> said that "usually the tunnel to the proxy is established using plain
> >>>> HTTP". When I try to return a route where the first hop (the hop to
> >>>> the
> >>>> proxy) is using HTTP then the secure flag of the route must not be
> >>>> "true". If you try then the following exception is raised:
> >>>>
> >>>> java.lang.IllegalStateException: Unable to establish route.
> >>>> planned = HttpRoute[{s}->http://localhost:8008->https://www.gmx.net]
> >>>> current = HttpRoute[{}->http://localhost:8008->https://www.gmx.net]
> >>>>
> >>>> I tracked the reason down and found that the isSecure method of the
> >>>> PlainSocketFactory always returns false. This means that if the
> >>>> proxy is
> >>>> accessed using http then the route must not be flagged to be
> >>>> secure. You
> >>>> said that if a route is flagged unsecure then "this will prevent
> >>>> HttpClient from sending cookies marked as secure".
> >>>>
> >>>> To summarize: If I want to contact a target host via a proxy by https
> >>>> and want to have cookies that are marked to be secure to be sent
> >>>> then I
> >>>> have to use https to contact the proxy and mark the route as being
> >>>> secure. Right?
> >>> Yes, you need to mark the route as secure but the initial connection
> >>> to the proxy should be made via HTTP. I have not come across an HTTP
> >>> proxy that supported CONNECT method via HTTPS.
> >>>
> >>>> In your last response you wrote, that for proxied https connections
> >>>> TunnelType.TUNELLED and LayerType.LAYERED should be choosen. When I
> >>>> return a route that uses https to access the proxy and the target
> >>>> host,
> >>>> that has its secure flag set to true and that is tunneled and
> >>>> layered, I
> >>>> get the following exception:
> >>>>
> >>> This problem has nothing to do with the route computation or even
> >>> HttpClient at all. The SSL context used by your application has not
> >>> been configured correctly.
> >>>
> >>>> javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
> >>>>         at
> >>>> com.sun.net.ssl.internal.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:352)
> >>>>
> >>>>
> >>>>         at
> >>>> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
> >>>>
> >>>>
> >>>>         at
> >>>> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:339)
> >>>>
> >>>>
> >>>>         at
> >>>> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:123)
> >>>>
> >>>>
> >>>>         at
> >>>> org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:147)
> >>>>
> >>>>
> >>>>         at
> >>>> org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:101)
> >>>>
> >>>>
> >>>>         at
> >>>> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:381)
> >>>>
> >>>>
> >>>>         at
> >>>> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:641)
> >>>>
> >>>>
> >>>>         at
> >>>> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:576)
> >>>>
> >>>>
> >>>>         at
> >>>> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:554)
> >>>>
> >>>>
> >>>>
> >>>> What is going wrong here? Does it mean that the proxy host needs to
> >>>> have
> >>>> a certifacate that is signed by a trusted certifaction authority?
> >>>>
> >>> I have no idea about expectations of your proxy host. Did CONNECT
> >>> method succeed?
> >>>
> >>>> Next try: If I choose a route that uses http to access the proxy host
> >>>> and https to access the target host and use TunnelType.PLAIN and
> >>>> LayerType.PLAIN then the route works. 
> >>> I suspect SSL/TLS is not being used in this case.
> >>>
> >>> The route should be marked as TunnelType.TUNELLED and
> >>> LayerType.LAYERED and the SSL context of your application must be set
> >>> up correctly.
> >>>
> >>> Why do you need a custom route planner in the first place?
> >>>
> >>> Oleg
> >>>
> >>>
> >>> Yet, this route can not be marked
> >>>> to be secure. This means that secure cookies are not sent!
> >>>>
> >>>> Thanks for you patience and help,
> >>>>
> >>>> --Stefan
> >>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> >>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> >> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

Re: Log creation appears to be a slowdown

2009-11-30T13:27:18Z

On Sat, 2009-11-28 at 17:01 +0000, Tony Poppleton wrote:
> Hi,
> 
> I have run a JProfiler on my application that uses HttpClient to send 
> requests every 10 milliseconds.  One interesting part of the results is 
> that the Log creation is actually consuming about 5% of the time, which 
> is significant considering I am trying to squeeze the most performance 
> out.  For example:
> 
>     public class ClientParamsStack extends AbstractHttpParams {
>         private final Log log = LogFactory.getLog(getClass());
> 
> I have always used static loggers myself, which avoid this problem, so I 
> did a tiny bit of research 
> (http://wiki.apache.org/jakarta-commons/Logging/StaticLog) and 
> apparently static isn't always the right choice.
> 
>
> Is there anything I can do to prevent the log creation from being a 
> slowdown, short of checking out the source tree and creating my own 
> custom patch?
> 
> I haven't investigated fully yet, but ClientParamsStack class seems to 
> be the main culprit, so is there any way I can set it to use my own 
> custom implementation of this?
> 

Tony,

If log creation does indeed have such an adverse effect on performance,
I would very much rather prefer to fix the problem in the library
itself. If you are reasonably sure performance can be improved by
eliminating certain log instances, please remove them and submit a patch
for inclusion into the official code base.

Cheers

Oleg  


> Many thanks,
> Tony
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

Re: implementation of a custom HttpRoutePlanner - how to choose the HttpRoute attributes (secure, tunnel type, and layer type)?

2009-11-30T09:42:18Z

Hi Oleg,

I implemented a small test case that demonstrates my problem. The
program uses a single proxy that is accessed by http (I use WebScarab).
When the program runs then I get the already mentioned illegal state
exception:

planned = HttpRoute[{s}->http://localhost:8008->https://www.gmx.net]
current = HttpRoute[{}->http://localhost:8008->https://www.gmx.net]
        at
org.apache.http.impl.client.DefaultRequestDirector.establishRoute(DefaultRequestDirector.java:672)
        at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:385)
        at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:641)
        at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:576)
        at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:554)
        at httpclienttest.Main.main(Main.java:68)

When I change the boolean tunneledAndLayered from false to true then I
get a SSLPeerUnverifiedException:

Exception in thread "main" javax.net.ssl.SSLPeerUnverifiedException:
peer not authenticated
        at
com.sun.net.ssl.internal.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:352)
        at
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
        at
org.apache.http.conn.ssl.SSLSocketFactory.createSocket(SSLSocketFactory.java:399)
        at
org.apache.http.impl.conn.DefaultClientConnectionOperator.updateSecureConnection(DefaultClientConnectionOperator.java:167)
        at
org.apache.http.impl.conn.AbstractPoolEntry.layerProtocol(AbstractPoolEntry.java:275)
        at
org.apache.http.impl.conn.AbstractPooledConnAdapter.layerProtocol(AbstractPooledConnAdapter.java:122)
        at
org.apache.http.impl.client.DefaultRequestDirector.establishRoute(DefaultRequestDirector.java:668)
        at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:385)
        at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:641)
        at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:576)
        at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:554)
        at httpclienttest.Main.main(Main.java:57)

You said that this exception is caused because the SSL context of the
application is not configured correctly. Unfortunately I do not how the
SSL context is configured. Can you please give me a hint.

Best regards,
--Stefan



package httpclienttest;

import org.apache.http.HttpException;
import org.apache.http.HttpHost;
import org.apache.http.HttpRequest;
import org.apache.http.client.methods.HttpGet;
import org.apache.http.client.methods.HttpUriRequest;
import org.apache.http.conn.ClientConnectionManager;
import org.apache.http.conn.routing.HttpRoute;
import org.apache.http.conn.routing.HttpRoutePlanner;
import org.apache.http.conn.routing.RouteInfo.LayerType;
import org.apache.http.conn.routing.RouteInfo.TunnelType;
import org.apache.http.conn.scheme.PlainSocketFactory;
import org.apache.http.conn.scheme.Scheme;
import org.apache.http.conn.scheme.SchemeRegistry;
import org.apache.http.conn.ssl.SSLSocketFactory;
import org.apache.http.impl.client.DefaultHttpClient;
import org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager;
import org.apache.http.params.BasicHttpParams;
import org.apache.http.params.HttpParams;
import org.apache.http.protocol.HttpContext;

public class Main {

  public static void main(String[] args) throws Exception {
    HttpParams httpParams = new BasicHttpParams();

    SchemeRegistry schemeRegistry = new SchemeRegistry();
    schemeRegistry.register(new Scheme("http",
PlainSocketFactory.getSocketFactory(), 80));
    schemeRegistry.register(new Scheme("https",
SSLSocketFactory.getSocketFactory(), 443));

    ClientConnectionManager connectionManager = new
ThreadSafeClientConnManager(httpParams, schemeRegistry);

    DefaultHttpClient httpClient = new
DefaultHttpClient(connectionManager, httpParams);

    HttpRoutePlanner routePlanner = new HttpRoutePlanner() {

      public HttpRoute determineRoute(HttpHost aTarget, HttpRequest
aRequest, HttpContext aContext) throws HttpException {

        HttpHost[] proxies = new HttpHost[1];
        proxies[0] = new HttpHost("localhost", 8008, "http");
        boolean isSecure = true;

        boolean tunneledAndLayered = false;
        TunnelType tunnelType = tunneledAndLayered ?
TunnelType.TUNNELLED : TunnelType.PLAIN;
        LayerType layerType = tunneledAndLayered ? LayerType.LAYERED :
LayerType.PLAIN;

        return new HttpRoute(aTarget, null, proxies, isSecure,
tunnelType, layerType);

      }

    };

    httpClient.setRoutePlanner(routePlanner);

    HttpUriRequest request = new HttpGet("https://www.gmx.net");
    httpClient.execute(request);

  }
}


Am 27.11.2009 22:29, schrieb Oleg Kalnichevski:
> Stefan Wachter wrote:
>> Hi Oleg,
>>
>> your proposal "you need to mark the route as secure but the initial
>> connection to the proxy should be made via HTTP" does not work. If the
>> route is planned in such a way then an IllegalStateException is raised
>> (as I mentioned in my last post). This is caused by the logic
>> implemented in HttpClient that a secure route can not use an insecure
>> connection.
>
> That does not seem to make any sense to me but I did not write HTTP
> route planning code. The default logic seems pretty straightforward.
>
> http://hc.apache.org/httpcomponents-client/httpclient/xref/org/apache/http/impl/conn/DefaultHttpRoutePlanner.html#111
>
>
> Please double-check your code and if you are convinced this is a bug
> in HttpClient please try to reproduce the problem with a test case.
>
> Oleg
>
>>
>> Can you please give me a hint how the SSL context of the application can
>> be configured correctly?
>>
>> Why I want to implement a custom route planner: I have integrated
>> HttpClient into an (web) application framework to allow easy access to
>> the HTTP protocol. I do not like the standard jvm proxy mechanism
>> because it is configured virtual machine wide and the configuration must
>> be done on the command line or by setting system properties. Using a
>> configurable custom route planner just would better fit into the overall
>> structure. I did not expect that implementing a custom route planner
>> would be so difficult. In addition, I like the possibilities for
>> connection pooling that HttpClient offers. I thought that in order to
>> configure the pooling for routes it is best to determine the by myself.
>> Otherwise I must have a close look at the routes that are returned by
>> the "ProxySelectorRoutePlanner".
>>
>> Thank you for your help,
>>
>> --Stefan
>>
>>
>>
>>
>> Am 27.11.2009 17:17, schrieb Oleg Kalnichevski:
>>> Stefan Wachter wrote:
>>>> Hi Oleg,
>>>>
>>>> I still struggle with the implementation of my HttpRoutePlanner.
>>>>
>>>> I try to establish an HTTPS connection to a target host via a
>>>> proxy. You
>>>> said that "usually the tunnel to the proxy is established using plain
>>>> HTTP". When I try to return a route where the first hop (the hop to
>>>> the
>>>> proxy) is using HTTP then the secure flag of the route must not be
>>>> "true". If you try then the following exception is raised:
>>>>
>>>> java.lang.IllegalStateException: Unable to establish route.
>>>> planned = HttpRoute[{s}->http://localhost:8008->https://www.gmx.net]
>>>> current = HttpRoute[{}->http://localhost:8008->https://www.gmx.net]
>>>>
>>>> I tracked the reason down and found that the isSecure method of the
>>>> PlainSocketFactory always returns false. This means that if the
>>>> proxy is
>>>> accessed using http then the route must not be flagged to be
>>>> secure. You
>>>> said that if a route is flagged unsecure then "this will prevent
>>>> HttpClient from sending cookies marked as secure".
>>>>
>>>> To summarize: If I want to contact a target host via a proxy by https
>>>> and want to have cookies that are marked to be secure to be sent
>>>> then I
>>>> have to use https to contact the proxy and mark the route as being
>>>> secure. Right?
>>> Yes, you need to mark the route as secure but the initial connection
>>> to the proxy should be made via HTTP. I have not come across an HTTP
>>> proxy that supported CONNECT method via HTTPS.
>>>
>>>> In your last response you wrote, that for proxied https connections
>>>> TunnelType.TUNELLED and LayerType.LAYERED should be choosen. When I
>>>> return a route that uses https to access the proxy and the target
>>>> host,
>>>> that has its secure flag set to true and that is tunneled and
>>>> layered, I
>>>> get the following exception:
>>>>
>>> This problem has nothing to do with the route computation or even
>>> HttpClient at all. The SSL context used by your application has not
>>> been configured correctly.
>>>
>>>> javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
>>>>         at
>>>> com.sun.net.ssl.internal.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:352)
>>>>
>>>>
>>>>         at
>>>> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
>>>>
>>>>
>>>>         at
>>>> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:339)
>>>>
>>>>
>>>>         at
>>>> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:123)
>>>>
>>>>
>>>>         at
>>>> org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:147)
>>>>
>>>>
>>>>         at
>>>> org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:101)
>>>>
>>>>
>>>>         at
>>>> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:381)
>>>>
>>>>
>>>>         at
>>>> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:641)
>>>>
>>>>
>>>>         at
>>>> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:576)
>>>>
>>>>
>>>>         at
>>>> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:554)
>>>>
>>>>
>>>>
>>>> What is going wrong here? Does it mean that the proxy host needs to
>>>> have
>>>> a certifacate that is signed by a trusted certifaction authority?
>>>>
>>> I have no idea about expectations of your proxy host. Did CONNECT
>>> method succeed?
>>>
>>>> Next try: If I choose a route that uses http to access the proxy host
>>>> and https to access the target host and use TunnelType.PLAIN and
>>>> LayerType.PLAIN then the route works. 
>>> I suspect SSL/TLS is not being used in this case.
>>>
>>> The route should be marked as TunnelType.TUNELLED and
>>> LayerType.LAYERED and the SSL context of your application must be set
>>> up correctly.
>>>
>>> Why do you need a custom route planner in the first place?
>>>
>>> Oleg
>>>
>>>
>>> Yet, this route can not be marked
>>>> to be secure. This means that secure cookies are not sent!
>>>>
>>>> Thanks for you patience and help,
>>>>
>>>> --Stefan
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

new ThreadSafeClientConnManager(...) freezes.

2009-11-29T01:44:00Z


Hello,


In my code, I do this:

System.out.println("yes1");

HttpParams params = new BasicHttpParams();

ConnManagerParams.setMaxTotalConnections(params, 100);

HttpProtocolParams.setVersion(params, HttpVersion.HTTP_1_1);

System.out.println("yes2");

SchemeRegistry schemeRegistry = new SchemeRegistry();

System.out.println("yes3");

schemeRegistry.register(new Scheme("http",
PlainSocketFactory.getSocketFactory(), 80));

System.out.println("yes4");

ClientConnectionManager cm = new
ThreadSafeClientConnManager(params,schemeRegistry);

System.out.println("yes5");


But when my program is moved into jars, I never get to see the "yes5"
message, nor is there any error or exception thrown, the thread just holds
there. It is like the new ThreadSafeClientConnManager(...) command freezes.
This doesn't occure in my Eclipse IDE. Does someone know what could cause
this, because it is driving me insane at the moment, and I don't see a way
out...


Greets,


Jonas
-- 
View this message in context: http://old.nabble.com/new-ThreadSafeClientConnManager%28...%29-freezes.-tp26558715p26558715.html
Sent from the HttpClient-User mailing list archive at Nabble.com.

Log creation appears to be a slowdown

2009-11-28T17:01:31Z

Hi,

I have run a JProfiler on my application that uses HttpClient to send 
requests every 10 milliseconds.  One interesting part of the results is 
that the Log creation is actually consuming about 5% of the time, which 
is significant considering I am trying to squeeze the most performance 
out.  For example:

    public class ClientParamsStack extends AbstractHttpParams {
        private final Log log = LogFactory.getLog(getClass());

I have always used static loggers myself, which avoid this problem, so I 
did a tiny bit of research 
(http://wiki.apache.org/jakarta-commons/Logging/StaticLog) and 
apparently static isn't always the right choice.

Is there anything I can do to prevent the log creation from being a 
slowdown, short of checking out the source tree and creating my own 
custom patch?

I haven't investigated fully yet, but ClientParamsStack class seems to 
be the main culprit, so is there any way I can set it to use my own 
custom implementation of this?

Many thanks,
Tony

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

Re: implementation of a custom HttpRoutePlanner - how to choose the HttpRoute attributes (secure, tunnel type, and layer type)?

2009-11-27T21:29:30Z

Stefan Wachter wrote:
> Hi Oleg,
> 
> your proposal "you need to mark the route as secure but the initial
> connection to the proxy should be made via HTTP" does not work. If the
> route is planned in such a way then an IllegalStateException is raised
> (as I mentioned in my last post). This is caused by the logic
> implemented in HttpClient that a secure route can not use an insecure
> connection.

That does not seem to make any sense to me but I did not write HTTP 
route planning code. The default logic seems pretty straightforward.

http://hc.apache.org/httpcomponents-client/httpclient/xref/org/apache/http/impl/conn/DefaultHttpRoutePlanner.html#111

Please double-check your code and if you are convinced this is a bug in 
HttpClient please try to reproduce the problem with a test case.

Oleg

> 
> Can you please give me a hint how the SSL context of the application can
> be configured correctly?
> 
> Why I want to implement a custom route planner: I have integrated
> HttpClient into an (web) application framework to allow easy access to
> the HTTP protocol. I do not like the standard jvm proxy mechanism
> because it is configured virtual machine wide and the configuration must
> be done on the command line or by setting system properties. Using a
> configurable custom route planner just would better fit into the overall
> structure. I did not expect that implementing a custom route planner
> would be so difficult. In addition, I like the possibilities for
> connection pooling that HttpClient offers. I thought that in order to
> configure the pooling for routes it is best to determine the by myself.
> Otherwise I must have a close look at the routes that are returned by
> the "ProxySelectorRoutePlanner".
> 
> Thank you for your help,
> 
> --Stefan
> 
> 
> 
> 
> Am 27.11.2009 17:17, schrieb Oleg Kalnichevski:
>> Stefan Wachter wrote:
>>> Hi Oleg,
>>>
>>> I still struggle with the implementation of my HttpRoutePlanner.
>>>
>>> I try to establish an HTTPS connection to a target host via a proxy. You
>>> said that "usually the tunnel to the proxy is established using plain
>>> HTTP". When I try to return a route where the first hop (the hop to the
>>> proxy) is using HTTP then the secure flag of the route must not be
>>> "true". If you try then the following exception is raised:
>>>
>>> java.lang.IllegalStateException: Unable to establish route.
>>> planned = HttpRoute[{s}->http://localhost:8008->https://www.gmx.net]
>>> current = HttpRoute[{}->http://localhost:8008->https://www.gmx.net]
>>>
>>> I tracked the reason down and found that the isSecure method of the
>>> PlainSocketFactory always returns false. This means that if the proxy is
>>> accessed using http then the route must not be flagged to be secure. You
>>> said that if a route is flagged unsecure then "this will prevent
>>> HttpClient from sending cookies marked as secure".
>>>
>>> To summarize: If I want to contact a target host via a proxy by https
>>> and want to have cookies that are marked to be secure to be sent then I
>>> have to use https to contact the proxy and mark the route as being
>>> secure. Right?
>> Yes, you need to mark the route as secure but the initial connection
>> to the proxy should be made via HTTP. I have not come across an HTTP
>> proxy that supported CONNECT method via HTTPS.
>>
>>> In your last response you wrote, that for proxied https connections
>>> TunnelType.TUNELLED and LayerType.LAYERED should be choosen. When I
>>> return a route that uses https to access the proxy and the target host,
>>> that has its secure flag set to true and that is tunneled and layered, I
>>> get the following exception:
>>>
>> This problem has nothing to do with the route computation or even
>> HttpClient at all. The SSL context used by your application has not
>> been configured correctly.
>>
>>> javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
>>>         at
>>> com.sun.net.ssl.internal.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:352)
>>>
>>>         at
>>> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
>>>
>>>         at
>>> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:339)
>>>
>>>         at
>>> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:123)
>>>
>>>         at
>>> org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:147)
>>>
>>>         at
>>> org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:101)
>>>
>>>         at
>>> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:381)
>>>
>>>         at
>>> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:641)
>>>
>>>         at
>>> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:576)
>>>
>>>         at
>>> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:554)
>>>
>>>
>>> What is going wrong here? Does it mean that the proxy host needs to have
>>> a certifacate that is signed by a trusted certifaction authority?
>>>
>> I have no idea about expectations of your proxy host. Did CONNECT
>> method succeed?
>>
>>> Next try: If I choose a route that uses http to access the proxy host
>>> and https to access the target host and use TunnelType.PLAIN and
>>> LayerType.PLAIN then the route works. 
>> I suspect SSL/TLS is not being used in this case.
>>
>> The route should be marked as TunnelType.TUNELLED and
>> LayerType.LAYERED and the SSL context of your application must be set
>> up correctly.
>>
>> Why do you need a custom route planner in the first place?
>>
>> Oleg
>>
>>
>> Yet, this route can not be marked
>>> to be secure. This means that secure cookies are not sent!
>>>
>>> Thanks for you patience and help,
>>>
>>> --Stefan
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

Re: implementation of a custom HttpRoutePlanner - how to choose the HttpRoute attributes (secure, tunnel type, and layer type)?

2009-11-27T18:05:06Z

Hi Oleg,

your proposal "you need to mark the route as secure but the initial
connection to the proxy should be made via HTTP" does not work. If the
route is planned in such a way then an IllegalStateException is raised
(as I mentioned in my last post). This is caused by the logic
implemented in HttpClient that a secure route can not use an insecure
connection.

Can you please give me a hint how the SSL context of the application can
be configured correctly?

Why I want to implement a custom route planner: I have integrated
HttpClient into an (web) application framework to allow easy access to
the HTTP protocol. I do not like the standard jvm proxy mechanism
because it is configured virtual machine wide and the configuration must
be done on the command line or by setting system properties. Using a
configurable custom route planner just would better fit into the overall
structure. I did not expect that implementing a custom route planner
would be so difficult. In addition, I like the possibilities for
connection pooling that HttpClient offers. I thought that in order to
configure the pooling for routes it is best to determine the by myself.
Otherwise I must have a close look at the routes that are returned by
the "ProxySelectorRoutePlanner".

Thank you for your help,

--Stefan




Am 27.11.2009 17:17, schrieb Oleg Kalnichevski:
> Stefan Wachter wrote:
>> Hi Oleg,
>>
>> I still struggle with the implementation of my HttpRoutePlanner.
>>
>> I try to establish an HTTPS connection to a target host via a proxy. You
>> said that "usually the tunnel to the proxy is established using plain
>> HTTP". When I try to return a route where the first hop (the hop to the
>> proxy) is using HTTP then the secure flag of the route must not be
>> "true". If you try then the following exception is raised:
>>
>> java.lang.IllegalStateException: Unable to establish route.
>> planned = HttpRoute[{s}->http://localhost:8008->https://www.gmx.net]
>> current = HttpRoute[{}->http://localhost:8008->https://www.gmx.net]
>>
>> I tracked the reason down and found that the isSecure method of the
>> PlainSocketFactory always returns false. This means that if the proxy is
>> accessed using http then the route must not be flagged to be secure. You
>> said that if a route is flagged unsecure then "this will prevent
>> HttpClient from sending cookies marked as secure".
>>
>> To summarize: If I want to contact a target host via a proxy by https
>> and want to have cookies that are marked to be secure to be sent then I
>> have to use https to contact the proxy and mark the route as being
>> secure. Right?
>
> Yes, you need to mark the route as secure but the initial connection
> to the proxy should be made via HTTP. I have not come across an HTTP
> proxy that supported CONNECT method via HTTPS.
>
>>
>> In your last response you wrote, that for proxied https connections
>> TunnelType.TUNELLED and LayerType.LAYERED should be choosen. When I
>> return a route that uses https to access the proxy and the target host,
>> that has its secure flag set to true and that is tunneled and layered, I
>> get the following exception:
>>
>
> This problem has nothing to do with the route computation or even
> HttpClient at all. The SSL context used by your application has not
> been configured correctly.
>
>> javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
>>         at
>> com.sun.net.ssl.internal.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:352)
>>
>>         at
>> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
>>
>>         at
>> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:339)
>>
>>         at
>> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:123)
>>
>>         at
>> org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:147)
>>
>>         at
>> org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:101)
>>
>>         at
>> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:381)
>>
>>         at
>> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:641)
>>
>>         at
>> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:576)
>>
>>         at
>> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:554)
>>
>>
>> What is going wrong here? Does it mean that the proxy host needs to have
>> a certifacate that is signed by a trusted certifaction authority?
>>
>
> I have no idea about expectations of your proxy host. Did CONNECT
> method succeed?
>
>> Next try: If I choose a route that uses http to access the proxy host
>> and https to access the target host and use TunnelType.PLAIN and
>> LayerType.PLAIN then the route works. 
>
> I suspect SSL/TLS is not being used in this case.
>
> The route should be marked as TunnelType.TUNELLED and
> LayerType.LAYERED and the SSL context of your application must be set
> up correctly.
>
> Why do you need a custom route planner in the first place?
>
> Oleg
>
>
> Yet, this route can not be marked
>> to be secure. This means that secure cookies are not sent!
>>
>> Thanks for you patience and help,
>>
>> --Stefan
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

RE: HttpConnection.isResponseAvailable

2009-11-27T16:50:47Z

Thanks again for the confirmation and input.

-ken

-----Original Message-----
From: Oleg Kalnichevski [mailto:olegk@apache.org] 
Sent: Thursday, November 26, 2009 3:48 PM
To: HttpClient User Discussion
Subject: Re: HttpConnection.isResponseAvailable

kenneth.s.brooks@chase.com wrote:
> Please validate this statement.
> 
> The IdleConnectionHandler kept firing past 20 seconds (my configured
> timeout value) because that connection was still active and waiting
for
> data.
> So it wasn't the IdleConnectionHandler that closed the socket,
otherwise
> I would have seen the following message "Closing connection,
connection
> time:".
> 
> 

Sounds about right.

As far as HttpClient is concerned any connection that is being used for 
transmitting messages is considered active. Connections are considered 
idle only when returned to the pool and not used for a certain period of

time.

Oleg


> 
> 
> That makes sense now looking at the source, because it looks like
> HttpMethodDirector caught an exception because that is where the stack
> is reporting it.. 
> 
>                 } catch (IOException e) {
>                     LOG.debug("Closing the connection.");
>                     this.conn.close();
> 
> and then just a little past that we see it saying that it did not
retry
> (I'm using a default retry handler) and throws the exception back to
the
> client.. which logged the Connection Reset.
>                     if (!handler.retryMethod(method, e, execCount)) {
>                         LOG.debug("Method retry handler returned
false.
> "
>                                 + "Automatic recovery will not be
> attempted");
>                         throw e;
>                     }
> 
> 
> Thanks for all of your input Oleg.. It is much appreciated.
> 
> 
> 
> -----Original Message-----
> From: Oleg Kalnichevski [mailto:olegk@apache.org] 
> Sent: Wednesday, November 25, 2009 5:12 PM
> To: HttpClient User Discussion
> Subject: Re: HttpConnection.isResponseAvailable
> 
> kenneth.s.brooks@chase.com wrote:
>> Related to previous post: Infinite loop in ChunkedInputStream.close
>>
>> Oleg,
>>
>> Last week I posted about an issue where we got the request body, and
>> when close is called on the input stream it gets to the underlying
>> InputStream.read and just sits there.
>> We ran some more tests with httpclient wire logging on and we
captured
> a
>> slightly different issue but stemming from the same apparent
> underlying
>> call.
>>
>> Both the previous issue and this one are both sitting idle at a call
> to
>> SocketInputStream.read (see the 'Client Log' further down this post
>> showing the stack trace where it is sitting).
>>
>> From what I see below it looks like the reply started to come, we get
>> the headers.. but it is sitting idle while checking for the response
>> body.
>> The VM isn't paused tho because the IdleConnectionHandler is
> continuing
>> to fire and (I think) eventually is responsible for closing the
>> connection. That is why we aren't getting a connection reset from the
>> loadbalancer in this case.
>>
>> So what in the world would would cause it to sit there?
>>  
> 
> The method blocks because the server is not sending any data whereas
it 
> clearly should be sending at least the closing chunk.
> 
> I do not see anything that could suggest there is a problem on the 
> client side.
> 
> Oleg
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> 
> This transmission may contain information that is privileged,
> confidential, legally privileged, and/or exempt from disclosure
> under applicable law.  If you are not the intended recipient, you
> are hereby notified that any disclosure, copying, distribution, or
> use of the information contained herein (including any reliance
> thereon) is STRICTLY PROHIBITED.  Although this transmission and
> any attachments are believed to be free of any virus or other
> defect that might affect any computer system into which it is
> received and opened, it is the responsibility of the recipient to
> ensure that it is virus free and no responsibility is accepted by
> JPMorgan Chase & Co., its subsidiaries and affiliates, as
> applicable, for any loss or damage arising in any way from its use.
>  If you received this transmission in error, please immediately
> contact the sender and destroy the material in its entirety,
> whether in electronic or hard copy format. Thank you.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

Re: implementation of a custom HttpRoutePlanner - how to choose the HttpRoute attributes (secure, tunnel type, and layer type)?

2009-11-27T16:17:02Z

Stefan Wachter wrote:
> Hi Oleg,
> 
> I still struggle with the implementation of my HttpRoutePlanner.
> 
> I try to establish an HTTPS connection to a target host via a proxy. You
> said that "usually the tunnel to the proxy is established using plain
> HTTP". When I try to return a route where the first hop (the hop to the
> proxy) is using HTTP then the secure flag of the route must not be
> "true". If you try then the following exception is raised:
> 
> java.lang.IllegalStateException: Unable to establish route.
> planned = HttpRoute[{s}->http://localhost:8008->https://www.gmx.net]
> current = HttpRoute[{}->http://localhost:8008->https://www.gmx.net]
> 
> I tracked the reason down and found that the isSecure method of the
> PlainSocketFactory always returns false. This means that if the proxy is
> accessed using http then the route must not be flagged to be secure. You
> said that if a route is flagged unsecure then "this will prevent
> HttpClient from sending cookies marked as secure".
> 
> To summarize: If I want to contact a target host via a proxy by https
> and want to have cookies that are marked to be secure to be sent then I
> have to use https to contact the proxy and mark the route as being
> secure. Right?

Yes, you need to mark the route as secure but the initial connection to 
the proxy should be made via HTTP. I have not come across an HTTP proxy 
that supported CONNECT method via HTTPS.

> 
> In your last response you wrote, that for proxied https connections
> TunnelType.TUNELLED and LayerType.LAYERED should be choosen. When I
> return a route that uses https to access the proxy and the target host,
> that has its secure flag set to true and that is tunneled and layered, I
> get the following exception:
> 

This problem has nothing to do with the route computation or even 
HttpClient at all. The SSL context used by your application has not been 
configured correctly.

> javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
>         at
> com.sun.net.ssl.internal.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:352)
>         at
> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
>         at
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:339)
>         at
> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:123)
>         at
> org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:147)
>         at
> org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:101)
>         at
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:381)
>         at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:641)
>         at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:576)
>         at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:554)
> 
> What is going wrong here? Does it mean that the proxy host needs to have
> a certifacate that is signed by a trusted certifaction authority?
> 

I have no idea about expectations of your proxy host. Did CONNECT method 
succeed?

> Next try: If I choose a route that uses http to access the proxy host
> and https to access the target host and use TunnelType.PLAIN and
> LayerType.PLAIN then the route works. 

I suspect SSL/TLS is not being used in this case.

The route should be marked as TunnelType.TUNELLED and LayerType.LAYERED 
and the SSL context of your application must be set up correctly.

Why do you need a custom route planner in the first place?

Oleg


Yet, this route can not be marked
> to be secure. This means that secure cookies are not sent!
> 
> Thanks for you patience and help,
> 
> --Stefan
>

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

Re: implementation of a custom HttpRoutePlanner - how to choose the HttpRoute attributes (secure, tunnel type, and layer type)?

2009-11-27T15:07:38Z

Hi Oleg,

I still struggle with the implementation of my HttpRoutePlanner.

I try to establish an HTTPS connection to a target host via a proxy. You
said that "usually the tunnel to the proxy is established using plain
HTTP". When I try to return a route where the first hop (the hop to the
proxy) is using HTTP then the secure flag of the route must not be
"true". If you try then the following exception is raised:

java.lang.IllegalStateException: Unable to establish route.
planned = HttpRoute[{s}->http://localhost:8008->https://www.gmx.net]
current = HttpRoute[{}->http://localhost:8008->https://www.gmx.net]

I tracked the reason down and found that the isSecure method of the
PlainSocketFactory always returns false. This means that if the proxy is
accessed using http then the route must not be flagged to be secure. You
said that if a route is flagged unsecure then "this will prevent
HttpClient from sending cookies marked as secure".

To summarize: If I want to contact a target host via a proxy by https
and want to have cookies that are marked to be secure to be sent then I
have to use https to contact the proxy and mark the route as being
secure. Right?

In your last response you wrote, that for proxied https connections
TunnelType.TUNELLED and LayerType.LAYERED should be choosen. When I
return a route that uses https to access the proxy and the target host,
that has its secure flag set to true and that is tunneled and layered, I
get the following exception:

javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
        at
com.sun.net.ssl.internal.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:352)
        at
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
        at
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:339)
        at
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:123)
        at
org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:147)
        at
org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:101)
        at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:381)
        at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:641)
        at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:576)
        at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:554)

What is going wrong here? Does it mean that the proxy host needs to have
a certifacate that is signed by a trusted certifaction authority?

Next try: If I choose a route that uses http to access the proxy host
and https to access the target host and use TunnelType.PLAIN and
LayerType.PLAIN then the route works. Yet, this route can not be marked
to be secure. This means that secure cookies are not sent!

Thanks for you patience and help,

--Stefan



Am 24.11.2009 10:38, schrieb Oleg Kalnichevski:
> On Mon, 2009-11-23 at 15:44 +0100, Stefan Wachter wrote:
>   
>> Hi Oleg,
>>
>> thank you for the additional information.
>>
>> You said, that the "secure" flag is "purely" arbitrary". Does this flag
>> have no effect at all on the way HttpClient behaves? Can I always set
>> this flag simply to "false"?
>>     
> You can, but this will prevent HttpClient from sending cookies marked as
> secure back to the origin server.
>
>
>   
>> Would the following rule for setting the TunnelType property correct?
>>
>> 1. Whenever there is a proxy between between the source and the target
>> host set the tunnel type to "TunnelType.TUNNELLED".
>>     
> No. Direct connection to the proxy does not always require tunneling.
> Tunneling is necessary only when sending data through a proxy using
> CONNECT method. That is, when the proxy cannot 'see' the data being
> transferred.  
>
>
>   
>> 2. Otherwise set the tunnel type to "TunnelType.PLAIN".
>>
>> Would the following rule for setting the LayerType property correct?
>>
>> 1. Whenever the target host is accessed by https set the layer type is
>> set to "LayerType.LAYERED".
>> 2. Otherwise set the layer type to "LayerType.PLAIN".
>>
>>     
> No. Layering can be used only if the connection is tunneled. 
>
> The default logic is actually fairly simple:
>
> direct HTTP connection: TunnelType.PLAIN, LayerType.PLAIN
> direct HTTPS connection: TunnelType.PLAIN, LayerType.PLAIN
> proxied HTTP connection: TunnelType.PLAIN, LayerType.PLAIN
> proxied HTTPS connection: TunnelType.TUNNELED, LayerType.LAYERED
>
> There can be some _really_ unusual cases when one might want to have a
> tunneled connection, which is non layered, hence the distinction between
> tunneling and layering.
>
> Oleg
>
>   
>> Thanks you for your help & best regards,
>>
>> --Stefan
>>
>>
>> Am 23.11.2009 11:47, schrieb Oleg Kalnichevski:
>>     
>>> On Sat, 2009-11-21 at 20:54 +0100, Stefan Wachter wrote:
>>>   
>>>       
>>>> Hi Oleg,
>>>>
>>>> thanks for your reply. I already have read the documentation and JavaDoc
>>>> carefully before I decided to ask on the mailing list. After reading the
>>>> docs again I still do not know how to set the three parameters secure,
>>>> tunnelled, and layered.
>>>>
>>>>     
>>>>         
>>> * Plain: direct connection to the target or a proxy
>>>
>>> * Tunneled: connection to a proxy or a proxy chain using CONNECT method.
>>> Once the connection is established the proxy will simply forward
>>> whatever data it receives from the client to the target server or next
>>> proxy
>>>
>>> * Layered: another protocol is 'layered' over the existing connection.  
>>>
>>> For example HTTPS via a proxy usually implies a tunneled and layered
>>> route. The client must establish a tunnel to the target server via the
>>> proxy and employ TLS/SSL as an additional protocol layer to encrypt/
>>> decrypt transmitted data. The tunneling proxy transfers data between the
>>> client and the target without looking at it.  
>>>
>>> A non tunneled route usually implies that the proxy must be able to look
>>> at the transmitted messages and rewrite them before passing on the
>>> recipient. 
>>>
>>>
>>>   
>>>       
>>>> For example if I want to access a target host by https and there is a
>>>> single proxy host in between. As far as I understand the proxy could be
>>>> contacted either by https or by http. This means there are the following
>>>> two alternatives:
>>>>
>>>> 1: source host -> (http) -> proxy host -> (https) -> target host
>>>> 2: source host -> (https) -> proxy host -> (https) -> target
host
>>>>
>>>>     
>>>>         
>>> I have never seen the second scenario ever used in real life. Usually
>>> the tunnel to the proxy is always established using plain HTTP.
>>>
>>>
>>>   
>>>       
>>>> What is the value for "secure" for these two alternatives? Can
>>>> alternative 1 be marked as secure (because the connection source ->
>>>> proxy is assumed to be in a secure intranet)? Is alternative 2 secure
>>>> because both enclosed connections are using https?
>>>>
>>>>     
>>>>         
>>> Secure flag is purely arbitrary. For instance plain routes within a
>>> controlled corporate network can be considered 'secure', whereas SSL
>>> connections with a weak cypher over a public network can be considered
>>> as insecure. The decision as to whether a route is secure or insecure is
>>> entirely up to you. HttpClient per default assumes that SSL connections
>>> can be considered as secure.
>>>
>>> Oleg  
>>>
>>>
>>>   
>>>       
>>>> What should the values for tunnelled and layered be?
>>>>
>>>> Thanks for your attention & best regards,
>>>>
>>>> --Stefan
>>>>
>>>>
>>>> Am 21.11.2009 14:11, schrieb Oleg Kalnichevski:
>>>>     
>>>>         
>>>>> Stefan Wachter wrote:
>>>>>       
>>>>>           
>>>>>> Hi all,
>>>>>>
>>>>>> I want to write a custom implementation of the HttpRoutePlanner
>>>>>> interface. The only method to implement is:
>>>>>>
>>>>>>       public HttpRoute determineRoute(HttpHost aTarget, HttpRequest
>>>>>> aRequest, HttpContext aContext) throws HttpException
>>>>>>
>>>>>> i.e. the method has to return an HttpRoute instance. There are various
>>>>>> constructors for an HttpRoute with the most general being:
>>>>>>
>>>>>>     public HttpRoute(HttpHost target, InetAddress local, HttpHost[]
>>>>>> proxies, boolean secure, TunnelType tunnelled, LayerType layered)
>>>>>>
>>>>>> I can determine the array of proxies because of my application logic,
>>>>>> but I am unsure which values the remaining parameters (secure,
>>>>>> tunnelled, and layered) should take.
>>>>>>
>>>>>> Could someone shed some light on these parameters? How do they effect
>>>>>> the behaviour of HttpClient?
>>>>>>
>>>>>>         
>>>>>>             
>>>>> http://hc.apache.org/httpcomponents-client/tutorial/html/connmgmt.html#d4e442
>>>>>
>>>>> http://hc.apache.org/httpcomponents-client/httpclient/apidocs/org/apache/http/conn/routing/RouteInfo.LayerType.html
>>>>>
>>>>> http://hc.apache.org/httpcomponents-client/httpclient/apidocs/org/apache/http/conn/routing/RouteInfo.TunnelType.html
>>>>>
>>>>>
>>>>> I hope this is enough
>>>>>
>>>>> Oleg
>>>>>
>>>>>       
>>>>>           
>>>>>> Best regards,
>>>>>> --Stefan
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>>>>>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>>>>>>
>>>>>>         
>>>>>>             
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>>>>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>>>>>
>>>>>       
>>>>>           
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>>>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>>>>
>>>>     
>>>>         
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>>>
>>>   
>>>       
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>>
>>     
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

Re: HttpConnection.isResponseAvailable

2009-11-26T20:47:55Z

kenneth.s.brooks@chase.com wrote:
> Please validate this statement.
> 
> The IdleConnectionHandler kept firing past 20 seconds (my configured
> timeout value) because that connection was still active and waiting for
> data.
> So it wasn't the IdleConnectionHandler that closed the socket, otherwise
> I would have seen the following message "Closing connection, connection
> time:".
> 
> 

Sounds about right.

As far as HttpClient is concerned any connection that is being used for 
transmitting messages is considered active. Connections are considered 
idle only when returned to the pool and not used for a certain period of 
time.

Oleg


> 
> 
> That makes sense now looking at the source, because it looks like
> HttpMethodDirector caught an exception because that is where the stack
> is reporting it.. 
> 
>                 } catch (IOException e) {
>                     LOG.debug("Closing the connection.");
>                     this.conn.close();
> 
> and then just a little past that we see it saying that it did not retry
> (I'm using a default retry handler) and throws the exception back to the
> client.. which logged the Connection Reset.
>                     if (!handler.retryMethod(method, e, execCount)) {
>                         LOG.debug("Method retry handler returned false.
> "
>                                 + "Automatic recovery will not be
> attempted");
>                         throw e;
>                     }
> 
> 
> Thanks for all of your input Oleg.. It is much appreciated.
> 
> 
> 
> -----Original Message-----
> From: Oleg Kalnichevski [mailto:olegk@apache.org] 
> Sent: Wednesday, November 25, 2009 5:12 PM
> To: HttpClient User Discussion
> Subject: Re: HttpConnection.isResponseAvailable
> 
> kenneth.s.brooks@chase.com wrote:
>> Related to previous post: Infinite loop in ChunkedInputStream.close
>>
>> Oleg,
>>
>> Last week I posted about an issue where we got the request body, and
>> when close is called on the input stream it gets to the underlying
>> InputStream.read and just sits there.
>> We ran some more tests with httpclient wire logging on and we captured
> a
>> slightly different issue but stemming from the same apparent
> underlying
>> call.
>>
>> Both the previous issue and this one are both sitting idle at a call
> to
>> SocketInputStream.read (see the 'Client Log' further down this post
>> showing the stack trace where it is sitting).
>>
>> From what I see below it looks like the reply started to come, we get
>> the headers.. but it is sitting idle while checking for the response
>> body.
>> The VM isn't paused tho because the IdleConnectionHandler is
> continuing
>> to fire and (I think) eventually is responsible for closing the
>> connection. That is why we aren't getting a connection reset from the
>> loadbalancer in this case.
>>
>> So what in the world would would cause it to sit there?
>>  
> 
> The method blocks because the server is not sending any data whereas it 
> clearly should be sending at least the closing chunk.
> 
> I do not see anything that could suggest there is a problem on the 
> client side.
> 
> Oleg
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> 
> This transmission may contain information that is privileged,
> confidential, legally privileged, and/or exempt from disclosure
> under applicable law.  If you are not the intended recipient, you
> are hereby notified that any disclosure, copying, distribution, or
> use of the information contained herein (including any reliance
> thereon) is STRICTLY PROHIBITED.  Although this transmission and
> any attachments are believed to be free of any virus or other
> defect that might affect any computer system into which it is
> received and opened, it is the responsibility of the recipient to
> ensure that it is virus free and no responsibility is accepted by
> JPMorgan Chase & Co., its subsidiaries and affiliates, as
> applicable, for any loss or damage arising in any way from its use.
>  If you received this transmission in error, please immediately
> contact the sender and destroy the material in its entirety,
> whether in electronic or hard copy format. Thank you.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

RE: HttpConnection.isResponseAvailable

2009-11-26T18:09:35Z

Please validate this statement.

The IdleConnectionHandler kept firing past 20 seconds (my configured
timeout value) because that connection was still active and waiting for
data.
So it wasn't the IdleConnectionHandler that closed the socket, otherwise
I would have seen the following message "Closing connection, connection
time:".

That makes sense now looking at the source, because it looks like
HttpMethodDirector caught an exception because that is where the stack
is reporting it.. 

                } catch (IOException e) {
                    LOG.debug("Closing the connection.");
                    this.conn.close();

and then just a little past that we see it saying that it did not retry
(I'm using a default retry handler) and throws the exception back to the
client.. which logged the Connection Reset.
                    if (!handler.retryMethod(method, e, execCount)) {
                        LOG.debug("Method retry handler returned false.
"
                                + "Automatic recovery will not be
attempted");
                        throw e;
                    }

Thanks for all of your input Oleg.. It is much appreciated.

-----Original Message-----
From: Oleg Kalnichevski [mailto:olegk@apache.org] 
Sent: Wednesday, November 25, 2009 5:12 PM
To: HttpClient User Discussion
Subject: Re: HttpConnection.isResponseAvailable

kenneth.s.brooks@chase.com wrote:
> Related to previous post: Infinite loop in ChunkedInputStream.close
> 
> Oleg,
> 
> Last week I posted about an issue where we got the request body, and
> when close is called on the input stream it gets to the underlying
> InputStream.read and just sits there.
> We ran some more tests with httpclient wire logging on and we captured
a
> slightly different issue but stemming from the same apparent
underlying
> call.
> 
> Both the previous issue and this one are both sitting idle at a call
to
> SocketInputStream.read (see the 'Client Log' further down this post
> showing the stack trace where it is sitting).
> 
> From what I see below it looks like the reply started to come, we get
> the headers.. but it is sitting idle while checking for the response
> body.
> The VM isn't paused tho because the IdleConnectionHandler is
continuing
> to fire and (I think) eventually is responsible for closing the
> connection. That is why we aren't getting a connection reset from the
> loadbalancer in this case.
> 
> So what in the world would would cause it to sit there?
>  

The method blocks because the server is not sending any data whereas it 
clearly should be sending at least the closing chunk.

I do not see anything that could suggest there is a problem on the 
client side.

Oleg

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law.  If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED.  Although this transmission and
any attachments are believed to be free of any virus or other
defect that might affect any computer system into which it is
received and opened, it is the responsibility of the recipient to
ensure that it is virus free and no responsibility is accepted by
JPMorgan Chase & Co., its subsidiaries and affiliates, as
applicable, for any loss or damage arising in any way from its use.
 If you received this transmission in error, please immediately
contact the sender and destroy the material in its entirety,
whether in electronic or hard copy format. Thank you.

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

Re: HttpConnection.isResponseAvailable

2009-11-25T22:11:32Z

kenneth.s.brooks@chase.com wrote:
> Related to previous post: Infinite loop in ChunkedInputStream.close
> 
> Oleg,
> 
> Last week I posted about an issue where we got the request body, and
> when close is called on the input stream it gets to the underlying
> InputStream.read and just sits there.
> We ran some more tests with httpclient wire logging on and we captured a
> slightly different issue but stemming from the same apparent underlying
> call.
> 
> Both the previous issue and this one are both sitting idle at a call to
> SocketInputStream.read (see the 'Client Log' further down this post
> showing the stack trace where it is sitting).
> 
> From what I see below it looks like the reply started to come, we get
> the headers.. but it is sitting idle while checking for the response
> body.
> The VM isn't paused tho because the IdleConnectionHandler is continuing
> to fire and (I think) eventually is responsible for closing the
> connection. That is why we aren't getting a connection reset from the
> loadbalancer in this case.
> 
> So what in the world would would cause it to sit there?
>  

The method blocks because the server is not sending any data whereas it 
clearly should be sending at least the closing chunk.

I do not see anything that could suggest there is a problem on the 
client side.

Oleg

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

HttpClient 4.0.1 and 4.1-alpha1 release preview

2009-11-25T21:01:12Z

Folks

There will be two releases of HttpClient very soon (likely next week). 
Please test your applications against the preview packages and report 
bugs if found

HttpClient 4.0.1
================
Release notes:
http://svn.apache.org/repos/asf/httpcomponents/httpclient/branches/4.0.x/RELEASE_NOTES.txt

Preview packages:
http://people.apache.org/~olegk/httpclient-4.0.1/

HttpClient 4.1 ALPHA1
================
Release notes:
http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/RELEASE_NOTES.txt

Preview packages:
http://people.apache.org/~olegk/httpclient-4.1-alpha1/

Oleg

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

Re: HttpClient blocks forever sometimes when open a HTTPS connection

2009-11-25T20:51:39Z

diegopatr wrote:
> Hi all,
> 
> I'm using HTTPClient together with Axis 2. My threads executes thousands of
> calls to webservices per day. Sometimes those threads blocks forever, none
> of the timeouts are executed and I need to restart the application. I have
> researched everything in the net but I can't found a solution.
> 
> I put the logs in TRACE mode. The last log message when a thread became
> blocked is always the same:
> 
> DEBUG org.apache.commons.httpclient.HttpConnection - Open connection to
> xxx.xxx.xxx.xxx:443
> 
> The next message should be:
> 
> TRACE org.apache.commons.httpclient.HttpMethodBase - enter
> HttpMethodBase.execute(HttpState, HttpConnection)
> 
> Which blocking operations are doing between this two points?
> 

Socket connect and SSL handshaking, which A LOT


> I have one MultiThreadedHttpConnectionManager and one HTTPClient shared
> between all the threads.
> 
> I setup it using this code:
> 
>         HttpConnectionManagerParams cmparams = new
> HttpConnectionManagerParams();
>         cmparams.setSoTimeout(timeout);
>         cmparams.setDefaultMaxConnectionsPerHost(100);
>         cmparams.setMaxTotalConnections(500);
>         cmparams.setConnectionTimeout(timeout);
>         cmparams.setTcpNoDelay(true);
> 
>         HttpClientParams params = new HttpClientParams();
>         params.setSoTimeout(timeout);
>         params.setConnectionManagerTimeout(timeout);
> 
>         conmgr = new MultiThreadedHttpConnectionManager();
>         conmgr.setParams(cmparams);
> 
>         httpClient = new HttpClient(params, conmgr);
> 
> What you suggested to resolve this problem? 
> 

Implement a custom socket factory which would give you a complete 
control over the process of connection setup.

Also consider upgrading to HttpClient 4.0

Oleg

> Thanks,
> Diego Patricio
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

HttpConnection.isResponseAvailable

2009-11-25T16:51:33Z

Related to previous post: Infinite loop in ChunkedInputStream.close

Oleg,

Last week I posted about an issue where we got the request body, and
when close is called on the input stream it gets to the underlying
InputStream.read and just sits there.
We ran some more tests with httpclient wire logging on and we captured a
slightly different issue but stemming from the same apparent underlying
call.

Both the previous issue and this one are both sitting idle at a call to
SocketInputStream.read (see the 'Client Log' further down this post
showing the stack trace where it is sitting).

From what I see below it looks like the reply started to come, we get
the headers.. but it is sitting idle while checking for the response
body.
The VM isn't paused tho because the IdleConnectionHandler is continuing
to fire and (I think) eventually is responsible for closing the
connection. That is why we aren't getting a connection reset from the
loadbalancer in this case.

So what in the world would would cause it to sit there?


As a little bit of a sidenote, we set the idleconnectiontimeout to 20
seconds.
        DEFAULT_PROPERTIES.setProperty(HTTP_IDLE_CONNECTION_TIMEOUT,
"20000");
 
DEFAULT_PROPERTIES.setProperty(HTTP_IDLE_CONNECTION_CHECK_INTERVAL,
"1000");

        IdleConnectionTimeoutThread idleConnectionTimeoutThread = new
IdleConnectionTimeoutThread();
 
idleConnectionTimeoutThread.setConnectionTimeout(ClientPropertyLocator.g
etInstance().getIntProperty(ClientPropertyLocator.HTTP_IDLE_CONNECTION_T
IMEOUT));
 
idleConnectionTimeoutThread.setTimeoutInterval(ClientPropertyLocator.get
Instance().getIntProperty(ClientPropertyLocator.HTTP_IDLE_CONNECTION_CHE
CK_INTERVAL));
 
idleConnectionTimeoutThread.addConnectionManager(connectionManager);
        idleConnectionTimeoutThread.start();
I'm a little confused as to why it waited 60 seconds. Only bringing it
up in case it is somehow relevant.


Thanks,
ken




==============
= HttpClient Wire log
==============


2009-11-25 01:58:25,714 DEBUG methods.PostMethod (PostMethod.java:152)
- enter PostMethod.clearRequestBody()
2009-11-25 01:58:25,714 DEBUG methods.EntityEnclosingMethod
(EntityEnclosingMethod.java:150)    - enter
EntityEnclosingMethod.clearRequestBody()
2009-11-25 01:58:25,714 DEBUG httpclient.HttpClient
(HttpClient.java:321)    - enter HttpClient.executeMethod(HttpMethod)
2009-11-25 01:58:25,714 DEBUG httpclient.HttpClient
(HttpClient.java:374)    - enter
HttpClient.executeMethod(HostConfiguration,HttpMethod,HttpState)
2009-11-25 01:58:25,714 DEBUG
httpclient.MultiThreadedHttpConnectionManager
(MultiThreadedHttpConnectionManager.java:405)    - enter
HttpConnectionManager.getConnectionWithTimeout(HostConfiguration, long)
2009-11-25 01:58:25,714 DEBUG
httpclient.MultiThreadedHttpConnectionManager
(MultiThreadedHttpConnectionManager.java:412)    -
HttpConnectionManager.getConnection:  config =
HostConfiguration[host=http://prf-services.mycompany.net:9810], timeout
= 0
2009-11-25 01:58:25,714 DEBUG
httpclient.MultiThreadedHttpConnectionManager
(MultiThreadedHttpConnectionManager.java:805)    - enter
HttpConnectionManager.ConnectionPool.getHostPool(HostConfiguration)
2009-11-25 01:58:25,714 DEBUG
httpclient.MultiThreadedHttpConnectionManager
(MultiThreadedHttpConnectionManager.java:805)    - enter
HttpConnectionManager.ConnectionPool.getHostPool(HostConfiguration)
2009-11-25 01:58:25,714 DEBUG
httpclient.MultiThreadedHttpConnectionManager
(MultiThreadedHttpConnectionManager.java:839)    - Getting free
connection,
hostConfig=HostConfiguration[host=http://prf-services.mycompany.net:9810
]
2009-11-25 01:58:25,714 DEBUG httpclient.HttpMethodDirector
(HttpMethodDirector.java:379)    - Attempt number 1 to process request
2009-11-25 01:58:25,714 DEBUG httpclient.HttpMethodBase
(HttpMethodBase.java:1079)    - enter HttpMethodBase.execute(HttpState,
HttpConnection)
2009-11-25 01:58:25,714 DEBUG httpclient.HttpMethodBase
(HttpMethodBase.java:2057)    - enter
HttpMethodBase.writeRequest(HttpState, HttpConnection)
2009-11-25 01:58:25,714 DEBUG httpclient.HttpMethodBase
(HttpMethodBase.java:2212)    - enter
HttpMethodBase.writeRequestLine(HttpState, HttpConnection)
2009-11-25 01:58:25,714 DEBUG httpclient.HttpMethodBase
(HttpMethodBase.java:1496)    - enter
HttpMethodBase.generateRequestLine(HttpConnection, String, String,
String, String)
2009-11-25 01:58:25,714 DEBUG wire.header       (Wire.java:70)    - >>
"POST /cms.rcts/2009.9.1.006/ccs/prf.lr/2008.8.1/CDC/essd-remote/
HTTP/1.1[\r][\n]"
2009-11-25 01:58:25,714 DEBUG httpclient.HttpConnection
(HttpConnection.java:1032)    - enter HttpConnection.print(String)
2009-11-25 01:58:25,714 DEBUG httpclient.HttpConnection
(HttpConnection.java:942)    - enter HttpConnection.write(byte[])
2009-11-25 01:58:25,714 DEBUG httpclient.HttpConnection
(HttpConnection.java:963)    - enter HttpConnection.write(byte[], int,
int)
2009-11-25 01:58:25,714 DEBUG httpclient.HttpMethodBase
(HttpMethodBase.java:2175)    - enter
HttpMethodBase.writeRequestHeaders(HttpState,HttpConnection)
2009-11-25 01:58:25,714 DEBUG methods.EntityEnclosingMethod
(EntityEnclosingMethod.java:370)    - enter
EntityEnclosingMethod.addRequestHeaders(HttpState, HttpConnection)
2009-11-25 01:58:25,714 DEBUG methods.ExpectContinueMethod
(ExpectContinueMethod.java:183)    - enter
ExpectContinueMethod.addRequestHeaders(HttpState, HttpConnection)
2009-11-25 01:58:25,714 DEBUG httpclient.HttpMethodBase
(HttpMethodBase.java:1417)    - enter
HttpMethodBase.addRequestHeaders(HttpState, HttpConnection)
2009-11-25 01:58:25,714 DEBUG httpclient.HttpMethodBase
(HttpMethodBase.java:1442)    - enter
HttpMethodBase.addUserAgentRequestHeaders(HttpState, HttpConnection)
2009-11-25 01:58:25,714 DEBUG httpclient.HttpMethodBase
(HttpMethodBase.java:1328)    - enter
HttpMethodBase.addHostRequestHeader(HttpState, HttpConnection)
2009-11-25 01:58:25,714 DEBUG httpclient.HttpMethodBase
(HttpMethodBase.java:1352)    - Adding Host request header
2009-11-25 01:58:25,714 DEBUG httpclient.HttpMethodBase
(HttpMethodBase.java:1266)    - enter
HttpMethodBase.addCookieRequestHeader(HttpState, HttpConnection)
2009-11-25 01:58:25,714 DEBUG httpclient.HttpState (HttpState.java:173)
- enter HttpState.getCookies()
2009-11-25 01:58:25,714 DEBUG httpclient.HttpMethodBase
(HttpMethodBase.java:1379)    - enter
HttpMethodBase.addProxyConnectionHeader(HttpState, HttpConnection)
2009-11-25 01:58:25,714 DEBUG methods.EntityEnclosingMethod
(EntityEnclosingMethod.java:401)    - enter
EntityEnclosingMethod.addContentLengthRequestHeader(HttpState,
HttpConnection)
2009-11-25 01:58:25,714 DEBUG methods.EntityEnclosingMethod
(EntityEnclosingMethod.java:325)    - enter
EntityEnclosingMethod.getRequestContentLength()
2009-11-25 01:58:25,714 DEBUG methods.PostMethod (PostMethod.java:135)
- enter PostMethod.hasRequestContent()
2009-11-25 01:58:25,714 DEBUG methods.EntityEnclosingMethod
(EntityEnclosingMethod.java:135)    - enter
EntityEnclosingMethod.hasRequestContent()
2009-11-25 01:58:25,730 DEBUG httpclient.HttpMethodBase
(HttpMethodBase.java:386)    - HttpMethodBase.addRequestHeader(Header)
2009-11-25 01:58:25,730 DEBUG wire.header       (Wire.java:70)    - >>
"Content-Type: application/x-java-serialized-object[\r][\n]"
2009-11-25 01:58:25,730 DEBUG httpclient.HttpConnection
(HttpConnection.java:1032)    - enter HttpConnection.print(String)
2009-11-25 01:58:25,730 DEBUG httpclient.HttpConnection
(HttpConnection.java:942)    - enter HttpConnection.write(byte[])
2009-11-25 01:58:25,730 DEBUG httpclient.HttpConnection
(HttpConnection.java:963)    - enter HttpConnection.write(byte[], int,
int)
2009-11-25 01:58:25,730 DEBUG wire.header       (Wire.java:70)    - >>
"Content-Encoding: none[\r][\n]"
2009-11-25 01:58:25,730 DEBUG httpclient.HttpConnection
(HttpConnection.java:1032)    - enter HttpConnection.print(String)
2009-11-25 01:58:25,730 DEBUG httpclient.HttpConnection
(HttpConnection.java:942)    - enter HttpConnection.write(byte[])
2009-11-25 01:58:25,730 DEBUG httpclient.HttpConnection
(HttpConnection.java:963)    - enter HttpConnection.write(byte[], int,
int)
2009-11-25 01:58:25,730 DEBUG wire.header       (Wire.java:70)    - >>
"Serialization-Type: java[\r][\n]"
2009-11-25 01:58:25,730 DEBUG httpclient.HttpConnection
(HttpConnection.java:1032)    - enter HttpConnection.print(String)
2009-11-25 01:58:25,730 DEBUG httpclient.HttpConnection
(HttpConnection.java:942)    - enter HttpConnection.write(byte[])
2009-11-25 01:58:25,730 DEBUG httpclient.HttpConnection
(HttpConnection.java:963)    - enter HttpConnection.write(byte[], int,
int)
2009-11-25 01:58:25,730 DEBUG wire.header       (Wire.java:70)    - >>
"User-Agent: Jakarta Commons-HttpClient/3.1[\r][\n]"
2009-11-25 01:58:25,730 DEBUG httpclient.HttpConnection
(HttpConnection.java:1032)    - enter HttpConnection.print(String)
2009-11-25 01:58:25,730 DEBUG httpclient.HttpConnection
(HttpConnection.java:942)    - enter HttpConnection.write(byte[])
2009-11-25 01:58:25,730 DEBUG httpclient.HttpConnection
(HttpConnection.java:963)    - enter HttpConnection.write(byte[], int,
int)
2009-11-25 01:58:25,730 DEBUG wire.header       (Wire.java:70)    - >>
"Host: prf-services.mycompany.net:9810[\r][\n]"
2009-11-25 01:58:25,730 DEBUG httpclient.HttpConnection
(HttpConnection.java:1032)    - enter HttpConnection.print(String)
2009-11-25 01:58:25,730 DEBUG httpclient.HttpConnection
(HttpConnection.java:942)    - enter HttpConnection.write(byte[])
2009-11-25 01:58:25,730 DEBUG httpclient.HttpConnection
(HttpConnection.java:963)    - enter HttpConnection.write(byte[], int,
int)
2009-11-25 01:58:25,730 DEBUG wire.header       (Wire.java:70)    - >>
"Content-Length: 5179[\r][\n]"
2009-11-25 01:58:25,730 DEBUG httpclient.HttpConnection
(HttpConnection.java:1032)    - enter HttpConnection.print(String)
2009-11-25 01:58:25,730 DEBUG httpclient.HttpConnection
(HttpConnection.java:942)    - enter HttpConnection.write(byte[])
2009-11-25 01:58:25,730 DEBUG httpclient.HttpConnection
(HttpConnection.java:963)    - enter HttpConnection.write(byte[], int,
int)
2009-11-25 01:58:25,730 DEBUG httpclient.HttpConnection
(HttpConnection.java:1001)    - enter HttpConnection.writeLine()
2009-11-25 01:58:25,730 DEBUG httpclient.HttpConnection
(HttpConnection.java:942)    - enter HttpConnection.write(byte[])
2009-11-25 01:58:25,730 DEBUG httpclient.HttpConnection
(HttpConnection.java:963)    - enter HttpConnection.write(byte[], int,
int)
2009-11-25 01:58:25,730 DEBUG wire.header       (Wire.java:70)    - >>
"[\r][\n]"
2009-11-25 01:58:25,730 DEBUG methods.EntityEnclosingMethod
(EntityEnclosingMethod.java:469)    - enter
EntityEnclosingMethod.writeRequestBody(HttpState, HttpConnection)
2009-11-25 01:58:25,730 DEBUG methods.PostMethod (PostMethod.java:135)
- enter PostMethod.hasRequestContent()
2009-11-25 01:58:25,730 DEBUG methods.EntityEnclosingMethod
(EntityEnclosingMethod.java:135)    - enter
EntityEnclosingMethod.hasRequestContent()
2009-11-25 01:58:25,730 DEBUG methods.EntityEnclosingMethod
(EntityEnclosingMethod.java:325)    - enter
EntityEnclosingMethod.getRequestContentLength()
2009-11-25 01:58:25,730 DEBUG methods.PostMethod (PostMethod.java:135)
- enter PostMethod.hasRequestContent()
2009-11-25 01:58:25,730 DEBUG methods.EntityEnclosingMethod
(EntityEnclosingMethod.java:135)    - enter
EntityEnclosingMethod.hasRequestContent()
2009-11-25 01:58:25,730 DEBUG httpclient.HttpConnection
(HttpConnection.java:840)    - enter
HttpConnection.getRequestOutputStream()
2009-11-25 01:58:25,730 DEBUG wire.content      (Wire.java:70)    - >>
"[0xac][0xed][0x0][0x5]sr[0x0]?com.fusa.ssg.infra.remoting.common.suppor
t.RemoteServiceRequest
[0x1b][0xcb][0xf7][0xe2].[0x14]o[0x2][0x0][0x5][[0x0][0x9]argumentst[0x0
][0x13][Ljava/lang/Object;L[0x0][\n]"
2009-11-25 01:58:25,730 DEBUG wire.content      (Wire.java:70)    - >>
"methodNamet[0x0][0x12]Ljava/lang/String;[[0x0][0xe]parameterTypest[0x0]
[0x12][Ljava/lang/Class;L[0x0][\r]securityTokenq[0x0]~[0x0][0x2]L[0x0][0
x10]serviceInterfacet[0x0][0x11]Ljava/lang/Class;xr[0x0]:com.fusa.ssg.in
fra.remoting.common.support.AttributeHolder[0xd6]][0xd8][0xc0][0xce]N[0x
85][0xa4][0x2][0x0][0x1]L[0x0][\n]"
2009-11-25 01:58:25,730 DEBUG wire.content      (Wire.java:70)    - >>
"attributest[0x0][0xf]Ljava/util/Map;xpsr[0x0][0x11]java.util.HashMap[0x
5][0x7][0xda][0xc1][0xc3][0x16]`[0xd1][0x3][0x0][0x2]F[0x0][\n]"
2009-11-25 01:58:25,730 DEBUG wire.content      (Wire.java:70)    - >>
"loadFactorI[0x0][0x9]thresholdxp?@[0x0][0x0][0x0][0x0][0x0][0xc]w[0x8][
0x0][0x0][0x0][0x10][0x0][0x0][0x0][0x1]t[0x0][0x9]auditInfosr[0x0][0x1f
]com.fusa.ssg.datatype.AuditInfo[0xa2][0xa9]5[0xc3][0xba]x@[0x93][0x2][0
x0][0x7]L[0x0][\r]correlationIdq[0x0]~[0x0][0x2]L[0x0][0x8]mChannelq[0x0
]~[0x0][0x2]L[0x0][0xc]mClientEvtIdq[0x0]~[0x0][0x2]L[0x0][0xe]mParentAu
ditIdt[0x0][0x10]Ljava/lang/Long;L[0x0][0xb]mPropertiesq[0x0]~[0x0][0x6]
L[0x0][0x7]mUserIdq[0x0]~[0x0][0x2]L[0x0][\n]"
2009-11-25 01:58:25,745 DEBUG wire.content      (Wire.java:70)    - >>
"operatorIdq[0x0]~[0x0][0x2]xpt[0x0]-ltu068_scd2nts044_-77fec0ce:125299e
cace:-7e72t[0x0][0x4]testppsr[0x0]%java.util.Collections$SynchronizedMap
[0x1b]s[0xf9][0x9]KK9{[0x3][0x0][0x2]L[0x0][0x1]mq[0x0]~[0x0][0x6]L[0x0]
[0x5]mutext[0x0][0x12]Ljava/lang/Object;xpsq[0x0]~[0x0][0x8]?@[0x0][0x0]
[0x0][0x0][0x0][0xc]w[0x8][0x0][0x0][0x0][0x10][0x0][0x0][0x0][0x5]t[0x0
][0xe]client-versiont[0x0][0xc]2009.9.1.006t[0x0][0x10]weblogic-versiont
[0x0][0x8]10.0.1.0t[0x0][\r]infra-versiont[0x0][0x9]4.3.PERF4t[0x0][0xc]
java-versiont[0x0][0x8]1.5.0_11t[0x0][0x7]machinet[0x0][0x1a]scd2nts044.
svr.bankone.netxq[0x0]~[0x0][0x12]xt[0x0][0x6]ltu068pxur[0x0][0x13][Ljav
a.lang.Object;[0x90][0xce]X[0x9f][0x10]s)l[0x2][0x0][0x0]xp[0x0][0x0][0x
0][0x3]sr[0x0][0xe]java.lang.Long;[0x8b][0xe4][0x90][0xcc][0x8f]#[0xdf][
0x2][0x0][0x1]J[0x0][0x5]valuexr[0x0][0x10]java.lang.Number[0x86][0xac][
0x95][0x1d][0xb][0x94][0xe0][0x8b][0x2][0x0][0x0]xp[0x0][0x0][0x0][0x0]D
yT[0xc6]sq[0x0]~[0x0]![0x0][0x0][0x0][0x0][0x0][0x0][0x3][0xe8]sr[0x0]*c
om.ccs.cco.cms.rcts.calltracking.WorkFlow[0xfe][0x99][0x15][0x2]&iy[0xf]
[0x2][0x0][0x2][[0x0][0x7]actionst[0x0]+[Lcom/ccs/cco/cms/rcts/calltrack
ing/Action;L[0x0][0xe]workFlowRecordt[0x0]2Lcom/ccs/cco/cms/rcts/calltra
cking/WorkFlowRecord;xpur[0x0]+[Lcom.ccs.cco.cms.rcts.calltracking.Actio
n;k[0xc6][[0xf4]2tY[0xd1][0x2][0x0][0x0]xp[0x0][0x0][0x0][0x1]sr[0x0](co
m.ccs.cco.cms.rcts.calltracking.Action[0xc][\r]$'D[0xaa][0x88]8[0x2][0x0
][0x5]L[0x0][0xc]actionRecordt[0x0]0Lcom/ccs/cco/cms/rcts/calltracking/A
ctionRecord;[[0x0][0xb]charRecordst[0x0]/[Lcom/ccs/cco/cms/rcts/calltrac
king/CharRecord;[[0x0][0xb]flagRecordst[0x0]/[Lcom/ccs/cco/cms/rcts/call
tracking/FlagRecord;[[0x0][0xc]floatRecordst[0x0]0[Lcom/ccs/cco/cms/rcts
/calltracking/FloatRecord;[[0x0][\n]"
2009-11-25 01:58:25,745 DEBUG wire.content      (Wire.java:70)    - >>
"intRecordst[0x0].[Lcom/ccs/cco/cms/rcts/calltracking/IntRecord;xpsr[0x0
].com.ccs.cco.cms.rcts.calltracking.ActionRecord[0xa7]Z[0x85][0xb3]/[0x9
e][0xdd][0x8d][0x2][0x0][0x8]L[0x0][0x11]callActnRsnTypeCdq[0x0]~[0x0][0
x2]L[0x0][0xe]callActnTypeCdq[0x0]~[0x0][0x2]L[0x0][\r]failureReasonq[0x
0]~[0x0][0x2]L[0x0][0xc]failutreTypeq[0x0]~[0x0][0x2]L[0x0][0xe]override
Reasonq[0x0]~[0x0][0x2]L[0x0][0xc]overrideTypeq[0x0]~[0x0][0x2]L[0x0][0x
8]passFailq[0x0]~[0x0][0x2]L[0x0][0xe]requrestorTypeq[0x0]~[0x0][0x2]xpt
[0x0][0x3]000t[0x0][0x3]300t[0x0][0x3]Perq[0x0]~[0x0]6q[0x0]~[0x0]6q[0x0
]~[0x0]4t[0x0][0x1]Yt[0x0][0x1]0ur[0x0]/[Lcom.ccs.cco.cms.rcts.calltrack
ing.CharRecord;][0xa3]f9[0xb6][0xca][0x91][0x88][0x2][0x0][0x0]xp[0x0][0
x0][0x0][0x1]sr[0x0],com.ccs.cco.cms.rcts.calltracking.CharRecord~[0xc0]
[0xba][0x83][0x91][0xe9][0xe9]f[0x2][0x0][0x4]L[0x0][0x5]char1q[0x0]~[0x
0][0x2]L[0x0][0x9]char1Typeq[0x0]~[0x0][0x2]L[0x0][0x5]char2q[0x0]~[0x0]
[0x2]L[0x0][0x9]char2Typeq[0x0]~[0x0][0x2]xpt[0x0][0xb]Perf
Authort[0x0][0x3]226q[0x0]~[0x0]=q[0x0]~[0x0]>ur[0x0]/[Lcom.ccs.cco.cms.
rcts.calltracking.FlagRecord;[0x19][0xed][0xc4][0xaa][0x9c]%s[0xe8][0x2]
[0x0][0x0]xp[0x0][0x0][0x0][0x1]sr[0x0],com.ccs.cco.cms.rcts.calltrackin
g.FlagRecord[0x17][0xb9][0xca]$[0x93][\r][0x12]^[0x2][0x0][0x4]L[0x0][0x
5]flag1q[0x0]~[0x0][0x2]L[0x0][0x9]flag1Typeq[0x0]~[0x0][0x2]L[0x0][0x5]
flag2q[0x0]~[0x0][0x2]L[0x0][0x9]flag2Typeq[0x0]~[0x0][0x2]xpt[0x0][0x1]
Ct[0x0][0x3]024t[0x0][0x1]Pq[0x0]~[0x0]4ur[0x0]0[Lcom.ccs.cco.cms.rcts.c
alltracking.FloatRecord;[0x84]W]k[0xe4][0x16][0x93]C[0x2][0x0][0x0]xp[0x
0][0x0][0x0][0x1]sr[0x0]-com.ccs.cco.cms.rcts.calltracking.FloatRecord"[
0xc6]}[0xdf][0xf0]![0xfb][0xd7][0x2][0x0][0x4]D[0x0][0x6]float1D[0x0][0x
6]float2L[0x0][\n]"
2009-11-25 01:58:25,745 DEBUG wire.content      (Wire.java:70)    - >>
"float1Typeq[0x0]~[0x0][0x2]L[0x0][\n]"
2009-11-25 01:58:25,745 DEBUG wire.content      (Wire.java:70)    - >>
"float2Typeq[0x0]~[0x0][0x2]xp@([0x0][0x0][0x0][0x0][0x0][0x0][0x0][0x0]
[0x0][0x0][0x0][0x0][0x0][0x0]t[0x0][0x3]050q[0x0]~[0x0]4ur[0x0].[Lcom.c
cs.cco.cms.rcts.calltracking.IntRecord;[0xbe][0xb1][0x97][0xe3][0xe0][0x
9]jw[0x2][0x0][0x0]xp[0x0][0x0][0x0][0x1]sr[0x0]+com.ccs.cco.cms.rcts.ca
lltracking.IntRecordz[0xea]>[0x8f]A[0xcd][0x8d][0xe2][0x2][0x0][0x4]J[0x
0][0x4]int1J[0x0][0x4]int2L[0x0][0x8]int1Typeq[0x0]~[0x0][0x2]L[0x0][0x8
]int2Typeq[0x0]~[0x0][0x2]xp[0x0][0x0][0x0][0x0][0x0][0x0][0x0][0x0][0x0
][0x0][0x0][0x0][0x0][0x0][0x0][0x0]t[0x0][0x3]004q[0x0]~[0x0]4sr[0x0]0c
om.ccs.cco.cms.rcts.calltracking.WorkFlowRecord[0xac][0x9a][0x81][0xcf][
0xeb][0x80][0xb7]&[0x2][0x0][0x7]I[0x0][\n]"
2009-11-25 01:58:25,745 DEBUG wire.content      (Wire.java:70)    - >>
"wfIntFlag1I[0x0][\n]"
2009-11-25 01:58:25,745 DEBUG wire.content      (Wire.java:84)    - >>
"wfIntFlag2J[0x0][0xf]wrkFlowDurationL[0x0][0xb]wfCharFlag1q[0x0]~[0x0][
0x2]L[0x0][0xb]wfCharFlag2q[0x0]~[0x0][0x2]L[0x0][\r]wfPreventableq[0x0]
~[0x0][0x2]L[0x0][\r]wrkFlowTypeCdq[0x0]~[0x0][0x2]xp[0x0][0x0][0x0][0x0
][0x0][0x0][0x0][0x0][0x0][0x0][0x0][0x0][0x0][0x0][0x0][0x3]t[0x0][0x1]
Nq[0x0]~[0x0]Rq[0x0]~[0x0]Rt[0x0][0x2]CCt[0x0][0xe]insertWorkFlowur[0x0]
[0x12][Ljava.lang.Class;[0xab][0x16][0xd7][0xae][0xcb][0xcd]Z[0x99][0x2]
[0x0][0x0]xp[0x0][0x0][0x0][0x3]vr[0x0][0x4]long[0x0][0x0][0x0][0x0][0x0
][0x0][0x0][0x0][0x0][0x0][0x0]xpq[0x0]~[0x0]Xvq[0x0]~[0x0]%t[0x7][0x94]
rO0ABXNyABtqYXZheC5zZWN1cml0eS5hdXRoLlN1YmplY3SMsjKTADP6aAMAAloACHJlYWRP
bmx5TAAKcHJpbmNpcGFsc3QAD0xqYXZhL3V0aWwvU2V0O3hwAHNyACVqYXZhLnV0aWwuQ29s
bGVjdGlvbnMkU3luY2hyb25pemVkU2V0BsPCeQLu3zwCAAB4cgAsamF2YS51dGlsLkNvbGxl
Y3Rpb25zJFN5bmNocm9uaXplZENvbGxlY3Rpb24qYfhNCZyZtQMAAkwAAWN0ABZMamF2YS91
dGlsL0NvbGxlY3Rpb247TAAFbXV0ZXh0ABJMamF2YS9sYW5nL09iamVjdDt4cHNyACVqYXZh
eC5zZWN1cml0eS5hdXRoLlN1YmplY3QkU2VjdXJlU2V0bcwygBdVficDAANJAAV3aGljaEwA
CGVsZW1lbnRzdAAWTGphdmEvdXRpbC9MaW5rZWRMaXN0O0wABnRoaXMkMHQAHUxqYXZheC9z
ZWN1cml0eS9hdXRoL1N1YmplY3Q7eHAAAAABc3IAFGphdmEudXRpbC5MaW5rZWRMaXN0DClT
XUpgiCIDAAB4cHcEAAAAAXN9AAAAAwAdd2VibG9naWMuc2VjdXJpdHkuc3BpLldMU1VzZXIA
KHdlYmxvZ2ljLnNlY3VyaXR5LnByaW5jaXBhbC5XTFNQcmluY2lwYWwAK2NvbS5mdXNhLnNz
Zy5pbmZyYS5zZWN1cml0eS5QcmluY2lwYWxIb2xkZXJ4cgAXamF2YS5sYW5nLnJlZmxlY3Qu
UHJveHnhJ9ogzBBDywIAAUwAAWh0ACVMamF2YS9sYW5nL3JlZmxlY3QvSW52b2NhdGlvbkhh
bmRsZXI7eHBzcgAuY29tLmZ1c2Euc3NnLmluZnJhLnNlY3VyaXR5LndsczgxLkNoYXNlV0xT
VXNlcg75OGXwolXPAgABTAAJY2hhc2VVc2VydAAtTGNvbS9mdXNhL3NzZy9pbmZyYS9zZWN1
cml0eS93bHM4MS9DaGFzZVVzZXI7eHIAL2NvbS5mdXNhLnNzZy5pbmZyYS5zZWN1cml0eS53
bHM4MS5CYXNlRGVjb3JhdG9ygZrIJ67g9dACAAFMAA13cmFwcGVkT2JqZWN0cQB+AAZ4cHNy
ACd3ZWJsb2dpYy5zZWN1cml0eS5wcmluY2lwYWwuV0xTVXNlckltcGy+Djjr39dsVQIAAHhy
ADB3ZWJsb2dpYy5zZWN1cml0eS5wcmluY2lwYWwuV0xTQWJzdHJhY3RQcmluY2lwYWyv/kb+
QWV+/AIAA0wABG5hbWV0ABJMamF2YS9sYW5nL1N0cmluZztbAARzYWx0dAACW0JbAAlzaWdu
YXR1cmVxAH4AGXhwdAAtbHR1MDY4L0N1c3RvbWVycmVwL1JlYXNvbl9Ob25lL0xUVTA2OC9T
TS90ZXN0dXIAAltCrPMX+AYIVOACAAB4cAAAAA0xMjU5MTIzNjkxMTI3dXEAfgAcAAAAEIxW
t0XEyA0po8iKakip1xZzcgArY29tLmZ1c2Euc3NnLmluZnJhLnNlY3VyaXR5LndsczgxLkNo
YXNlVXNlcsAgWGdf7AYfAgACTAAIdXNlck5hbWVxAH4AGEwACXVzZXJQcm9wc3QAFkxqYXZh
L3V0aWwvUHJvcGVydGllczt4cHQALWx0dTA2OC9DdXN0b21lcnJlcC9SZWFzb25fTm9uZS9M
VFUwNjgvU00vdGVzdHNyABRqYXZhLnV0aWwuUHJvcGVydGllczkS0HpwNj6YAgABTAAIZGVm
YXVsdHNxAH4AIHhyABNqYXZhLnV0aWwuSGFzaHRhYmxlE7sPJSFK5LgDAAJGAApsb2FkRmFj
dG9ySQAJdGhyZXNob2xkeHA/QAAAAAAACHcIAAAACwAAAAB4cHhxAH4AAnhxAH4AB3h4vr[0
x0]6com.ccs.cco.cms.rcts.calltracking.ICallTrackingService[0x0][0x0][0x0
][0x0][0x0][0x0][0x0][0x0][0x0][0x0][0x0]xp"
2009-11-25 01:58:25,745 DEBUG methods.EntityEnclosingMethod
(EntityEnclosingMethod.java:508)    - Request body sent
2009-11-25 01:58:25,745 DEBUG httpclient.HttpConnection
(HttpConnection.java:826)    - enter
HttpConnection.flushRequestOutputStream()
2009-11-25 01:58:25,745 DEBUG httpclient.HttpMethodBase
(HttpMethodBase.java:1730)    - enter
HttpMethodBase.readResponse(HttpState, HttpConnection)
2009-11-25 01:58:25,745 DEBUG httpclient.HttpMethodBase
(HttpMethodBase.java:1964)    - enter
HttpMethodBase.readStatusLine(HttpState, HttpConnection)
2009-11-25 01:58:25,745 DEBUG httpclient.HttpConnection
(HttpConnection.java:1113)    - enter HttpConnection.readLine()
2009-11-25 01:58:25,745 DEBUG httpclient.HttpParser
(HttpParser.java:105)    - enter HttpParser.readLine(InputStream,
String)
2009-11-25 01:58:25,745 DEBUG httpclient.HttpParser (HttpParser.java:74)
- enter HttpParser.readRawLine()
2009-11-25 01:58:25,761 DEBUG wire.header       (Wire.java:70)    - <<
"HTTP/1.1 200 OK[\r][\n]"
2009-11-25 01:58:25,761 DEBUG wire.header       (Wire.java:70)    - <<
"HTTP/1.1 200 OK[\r][\n]"
2009-11-25 01:58:25,761 DEBUG httpclient.HttpMethodBase
(HttpMethodBase.java:1930)    - enter
HttpMethodBase.readResponseHeaders(HttpState,HttpConnection)
2009-11-25 01:58:25,761 DEBUG httpclient.HttpConnection
(HttpConnection.java:857)    - enter
HttpConnection.getResponseInputStream()
2009-11-25 01:58:25,761 DEBUG httpclient.HttpParser
(HttpParser.java:170)    - enter HeaderParser.parseHeaders(InputStream,
String)
2009-11-25 01:58:25,761 DEBUG httpclient.HttpParser
(HttpParser.java:105)    - enter HttpParser.readLine(InputStream,
String)
2009-11-25 01:58:25,761 DEBUG httpclient.HttpParser (HttpParser.java:74)
- enter HttpParser.readRawLine()
2009-11-25 01:58:25,761 DEBUG wire.header       (Wire.java:70)    - <<
"Date: Wed, 25 Nov 2009 06:58:27 GMT[\r][\n]"
2009-11-25 01:58:25,761 DEBUG httpclient.HttpParser
(HttpParser.java:105)    - enter HttpParser.readLine(InputStream,
String)
2009-11-25 01:58:25,761 DEBUG httpclient.HttpParser (HttpParser.java:74)
- enter HttpParser.readRawLine()
2009-11-25 01:58:25,761 DEBUG wire.header       (Wire.java:70)    - <<
"Transfer-Encoding: chunked[\r][\n]"
2009-11-25 01:58:25,761 DEBUG httpclient.HttpParser
(HttpParser.java:105)    - enter HttpParser.readLine(InputStream,
String)
2009-11-25 01:58:25,761 DEBUG httpclient.HttpParser (HttpParser.java:74)
- enter HttpParser.readRawLine()
2009-11-25 01:58:25,761 DEBUG wire.header       (Wire.java:70)    - <<
"Content-Type: application/x-java-serialized-object[\r][\n]"
2009-11-25 01:58:25,761 DEBUG httpclient.HttpParser
(HttpParser.java:105)    - enter HttpParser.readLine(InputStream,
String)
2009-11-25 01:58:25,761 DEBUG httpclient.HttpParser (HttpParser.java:74)
- enter HttpParser.readRawLine()
2009-11-25 01:58:25,761 DEBUG wire.header       (Wire.java:70)    - <<
"Content-Encoding: none[\r][\n]"
2009-11-25 01:58:25,761 DEBUG httpclient.HttpParser
(HttpParser.java:105)    - enter HttpParser.readLine(InputStream,
String)
2009-11-25 01:58:25,761 DEBUG httpclient.HttpParser (HttpParser.java:74)
- enter HttpParser.readRawLine()
2009-11-25 01:58:25,761 DEBUG wire.header       (Wire.java:70)    - <<
"Serialization-Type: java[\r][\n]"
2009-11-25 01:58:25,761 DEBUG httpclient.HttpParser
(HttpParser.java:105)    - enter HttpParser.readLine(InputStream,
String)
2009-11-25 01:58:25,761 DEBUG httpclient.HttpParser (HttpParser.java:74)
- enter HttpParser.readRawLine()
2009-11-25 01:58:25,761 DEBUG wire.header       (Wire.java:70)    - <<
"[\r][\n]"
2009-11-25 01:58:25,761 DEBUG httpclient.HttpMethodBase
(HttpMethodBase.java:1579)    - enter
HttpMethodBase.processResponseHeaders(HttpState, HttpConnection)
2009-11-25 01:58:25,761 DEBUG httpclient.HttpMethodBase
(HttpMethodBase.java:1615)    - enter
HttpMethodBase.processCookieHeaders(Header[], HttpState, HttpConnection)
2009-11-25 01:58:25,761 DEBUG httpclient.HttpMethodBase
(HttpMethodBase.java:1781)    - enter
HttpMethodBase.readResponseBody(HttpState, HttpConnection)
2009-11-25 01:58:25,761 DEBUG httpclient.HttpMethodBase
(HttpMethodBase.java:1816)    - enter
HttpMethodBase.readResponseBody(HttpConnection)
2009-11-25 01:58:25,761 DEBUG httpclient.HttpConnection
(HttpConnection.java:857)    - enter
HttpConnection.getResponseInputStream()
2009-11-25 01:58:25,761 DEBUG httpclient.HttpMethodBase
(HttpMethodBase.java:2281)    - enter
HttpMethodBase.canResponseHaveBody(int)
2009-11-25 01:58:25,761 DEBUG httpclient.HeaderElement
(HeaderElement.java:238)    - enter HeaderElement.parseElements(String)
2009-11-25 01:58:25,761 DEBUG httpclient.HeaderElement
(HeaderElement.java:194)    - enter HeaderElement.parseElements(char[])
2009-11-25 01:58:25,761 DEBUG httpclient.HttpConnection
(HttpConnection.java:894)    - enter
HttpConnection.isResponseAvailable(int)
2009-11-25 01:58:26,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132286355
2009-11-25 01:58:27,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132287355
2009-11-25 01:58:28,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132288355
2009-11-25 01:58:29,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132289355
2009-11-25 01:58:30,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132290355
2009-11-25 01:58:31,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132291355
2009-11-25 01:58:32,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132292355
2009-11-25 01:58:33,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132293355
2009-11-25 01:58:34,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132294355
2009-11-25 01:58:35,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132295355
2009-11-25 01:58:36,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132296355
2009-11-25 01:58:37,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132297355
2009-11-25 01:58:38,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132298355
2009-11-25 01:58:39,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132299355
2009-11-25 01:58:40,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132300355
2009-11-25 01:58:41,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132301355
2009-11-25 01:58:42,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132302355
2009-11-25 01:58:43,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132303355
2009-11-25 01:58:44,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132304355
2009-11-25 01:58:45,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132305355
2009-11-25 01:58:46,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132306355
2009-11-25 01:58:47,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132307355
2009-11-25 01:58:48,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132308355
2009-11-25 01:58:49,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132309355
2009-11-25 01:58:50,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132310355
2009-11-25 01:58:51,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132311355
2009-11-25 01:58:52,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132312355
2009-11-25 01:58:53,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132313355
2009-11-25 01:58:54,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132314355
2009-11-25 01:58:55,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132315355
2009-11-25 01:58:56,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132316355
2009-11-25 01:58:57,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132317355
2009-11-25 01:58:58,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132318355
2009-11-25 01:58:59,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132319355
2009-11-25 01:59:00,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132320355
2009-11-25 01:59:01,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132321355
2009-11-25 01:59:02,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132322355
2009-11-25 01:59:03,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132323355
2009-11-25 01:59:04,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132324355
2009-11-25 01:59:05,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132325355
2009-11-25 01:59:06,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132326355
2009-11-25 01:59:07,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132327355
2009-11-25 01:59:08,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132328355
2009-11-25 01:59:09,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132329355
2009-11-25 01:59:10,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132330355
2009-11-25 01:59:11,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132331355
2009-11-25 01:59:12,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132332355
2009-11-25 01:59:13,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132333355
2009-11-25 01:59:14,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132334355
2009-11-25 01:59:15,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132335355
2009-11-25 01:59:16,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132336355
2009-11-25 01:59:17,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132337355
2009-11-25 01:59:18,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132338355
2009-11-25 01:59:19,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132339355
2009-11-25 01:59:20,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132340355
2009-11-25 01:59:21,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132341355
2009-11-25 01:59:22,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132342355
2009-11-25 01:59:23,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132343355
2009-11-25 01:59:24,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132344355
2009-11-25 01:59:25,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132345355
2009-11-25 01:59:25,792 DEBUG httpclient.HttpMethodDirector
(HttpMethodDirector.java:404)    - Closing the connection.
2009-11-25 01:59:25,792 DEBUG httpclient.HttpConnection
(HttpConnection.java:1148)    - enter HttpConnection.close()
2009-11-25 01:59:25,792 DEBUG httpclient.HttpConnection
(HttpConnection.java:1215)    - enter
HttpConnection.closeSockedAndStreams()
2009-11-25 01:59:25,792 DEBUG httpclient.HttpMethodDirector
(HttpMethodDirector.java:434)    - Method retry handler returned false.
Automatic recovery will not be attempted
2009-11-25 01:59:25,792 DEBUG httpclient.HttpConnection
(HttpConnection.java:1174)    - enter HttpConnection.releaseConnection()
2009-11-25 01:59:25,792 DEBUG httpclient.HttpConnection
(HttpConnection.java:1178)    - Releasing connection back to connection
manager.
2009-11-25 01:59:25,792 DEBUG
httpclient.MultiThreadedHttpConnectionManager
(MultiThreadedHttpConnectionManager.java:630)    - enter
HttpConnectionManager.releaseConnection(HttpConnection)
2009-11-25 01:59:25,792 DEBUG
httpclient.MultiThreadedHttpConnectionManager
(MultiThreadedHttpConnectionManager.java:979)    - Freeing connection,
hostConfig=HostConfiguration[host=http://prf-services.mycompany.net:9810
]
2009-11-25 01:59:25,792 DEBUG
httpclient.MultiThreadedHttpConnectionManager
(MultiThreadedHttpConnectionManager.java:805)    - enter
HttpConnectionManager.ConnectionPool.getHostPool(HostConfiguration)
2009-11-25 01:59:25,792 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:76)    - Adding connection at: 1259132365792
2009-11-25 01:59:25,792 DEBUG
httpclient.MultiThreadedHttpConnectionManager
(MultiThreadedHttpConnectionManager.java:961)    - Notifying no-one,
there are no waiting threads
2009-11-25 01:59:26,355 DEBUG util.IdleConnectionHandler
(IdleConnectionHandler.java:108)    - Checking for connections,
idleTimeout: 1259132346355
2009-11-25 01:59:26,355 DEBUG
httpclient.MultiThreadedHttpConnectionManager
(MultiThreadedHttpConnectionManager.java:889)    - Reclaiming
connection,
hostConfig=HostConfiguration[host=http://prf-services.mycompany.net:9810
]
2009-11-25 01:59:26,355 DEBUG httpclient.HttpConnection
(HttpConnection.java:1148)    - enter HttpConnection.close()
2009-11-25 01:59:26,355 DEBUG httpclient.HttpConnection
(HttpConnection.java:1215)    - enter
HttpConnection.closeSockedAndStreams()
2009-11-25 01:59:26,355 DEBUG
httpclient.MultiThreadedHttpConnectionManager
(MultiThreadedHttpConnectionManager.java:805)    - enter
HttpConnectionManager.ConnectionPool.getHostPool(HostConfiguration)




==========
= Client Log - Shows that the request was sent and 1 minute later the
connection was reset.
==========

25-Nov-2009:01:58:25.714	scd2nts044	main	INFO
ICallTrackingService.createAuditInfo()		NA	Created
correlation id[ltu068_scd2nts044_-77fec0ce:125299ecace:-7e72] for
mChannel=test;mUserId=ltu068;mParentAuditId=null;correlationId=null;oper
atorId=null
25-Nov-2009:01:59:25.792	scd2nts044	main	EXCEPTION
ICallTrackingService.insertWorkFlow	callId = 1148802246, wfIndex =
1000, workFlow_in = com.ccs.cco.cms.rcts.calltracking.WorkFlow@9578c1
ltu068_scd2nts044_-77fec0ce:125299ecace:-7e72	SYSTEM_EXCEPTION[Error
making call[Error executing Remote Method=[insertWorkFlow] for Service
Url=[http://prf-services.mycompany.net:9810/cms.rcts/2009.9.1.006/ccs/pr
f.lr/2008.8.1/CDC] Exception=[java.net.SocketException: Connection reset
	at java.net.SocketInputStream.read(SocketInputStream.java:168)
	at
java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
	at
java.io.BufferedInputStream.read(BufferedInputStream.java:235)
	at
org.apache.commons.httpclient.HttpConnection.isResponseAvailable(HttpCon
nection.java:903)
	at
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpCon
nectionAdapter.isResponseAvailable(MultiThreadedHttpConnectionManager.ja
va:1337)
	at
org.apache.commons.httpclient.HttpMethodBase.readResponseBody(HttpMethod
Base.java:1843)
	at
org.apache.commons.httpclient.HttpMethodBase.readResponseBody(HttpMethod
Base.java:1785)
	at
org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase
.java:1748)
	at
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java
:1098)
	at
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMe
thodDirector.java:398)
	at
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMetho
dDirector.java:171)
	at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:3
97)
	at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:3
23)
	at
com.fusa.ssg.infra.remoting.client.service.RemoteServiceExecutorImpl.exe
cuteRequest(RemoteServiceExecutorImpl.java:99)
	at
com.fusa.ssg.infra.remoting.client.service.RemoteServiceProxy.invoke(Rem
oteServiceProxy.java:54)
	at $Proxy1.insertWorkFlow(Unknown Source)
	at
com.ccs.cco.cms.rcts.client.calltracking.CallTrackingRemotingDelegate.in
sertWorkFlow(CallTrackingRemotingDelegate.java:210)
	at Actions.action(Actions.java:2344)
]]]
com.fusa.ssg.SystemException: Error making call[Error executing Remote
Method=[insertWorkFlow] for Service
Url=[http://prf-services.mycompany.net:9810/cms.rcts/2009.9.1.006/ccs/pr
f.lr/2008.8.1/CDC] Exception=[java.net.SocketException: Connection reset
	at java.net.SocketInputStream.read(SocketInputStream.java:168)
	at
java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
	at
java.io.BufferedInputStream.read(BufferedInputStream.java:235)
	at
org.apache.commons.httpclient.HttpConnection.isResponseAvailable(HttpCon
nection.java:903)
	at
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpCon
nectionAdapter.isResponseAvailable(MultiThreadedHttpConnectionManager.ja
va:1337)
	at
org.apache.commons.httpclient.HttpMethodBase.readResponseBody(HttpMethod
Base.java:1843)
	at
org.apache.commons.httpclient.HttpMethodBase.readResponseBody(HttpMethod
Base.java:1785)
	at
org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase
.java:1748)
	at
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java
:1098)
	at
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMe
thodDirector.java:398)
	at
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMetho
dDirector.java:171)
	at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:3
97)
	at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:3
23)
	at
com.fusa.ssg.infra.remoting.client.service.RemoteServiceExecutorImpl.exe
cuteRequest(RemoteServiceExecutorImpl.java:99)
	at
com.fusa.ssg.infra.remoting.client.service.RemoteServiceProxy.invoke(Rem
oteServiceProxy.java:54)
	at $Proxy1.insertWorkFlow(Unknown Source)
	at
com.ccs.cco.cms.rcts.client.calltracking.CallTrackingRemotingDelegate.in
sertWorkFlow(CallTrackingRemotingDelegate.java:210)
	at Actions.action(Actions.java:2344)
]]
	at
com.ccs.cco.cms.rcts.client.calltracking.CallTrackingRemotingDelegate.in
sertWorkFlow(CallTrackingRemotingDelegate.java:222)
	at Actions.action(Actions.java:2344)
------------Wrapped Exception-----------
com.fusa.ssg.infra.remoting.common.RemoteServiceException: Error
executing Remote Method=[insertWorkFlow] for Service
Url=[http://prf-services.mycompany.net:9810/cms.rcts/2009.9.1.006/ccs/pr
f.lr/2008.8.1/CDC] Exception=[java.net.SocketException: Connection reset
	at java.net.SocketInputStream.read(SocketInputStream.java:168)
	at
java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
	at
java.io.BufferedInputStream.read(BufferedInputStream.java:235)
	at
org.apache.commons.httpclient.HttpConnection.isResponseAvailable(HttpCon
nection.java:903)
	at
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpCon
nectionAdapter.isResponseAvailable(MultiThreadedHttpConnectionManager.ja
va:1337)
	at
org.apache.commons.httpclient.HttpMethodBase.readResponseBody(HttpMethod
Base.java:1843)
	at
org.apache.commons.httpclient.HttpMethodBase.readResponseBody(HttpMethod
Base.java:1785)
	at
org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase
.java:1748)
	at
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java
:1098)
	at
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMe
thodDirector.java:398)
	at
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMetho
dDirector.java:171)
	at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:3
97)
	at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:3
23)
	at
com.fusa.ssg.infra.remoting.client.service.RemoteServiceExecutorImpl.exe
cuteRequest(RemoteServiceExecutorImpl.java:99)
	at
com.fusa.ssg.infra.remoting.client.service.RemoteServiceProxy.invoke(Rem
oteServiceProxy.java:54)
	at $Proxy1.insertWorkFlow(Unknown Source)
	at
com.ccs.cco.cms.rcts.client.calltracking.CallTrackingRemotingDelegate.in
sertWorkFlow(CallTrackingRemotingDelegate.java:210)
	at Actions.action(Actions.java:2344)
]
	at
com.fusa.ssg.infra.remoting.client.service.RemoteServiceProxy.invoke(Rem
oteServiceProxy.java:58)
	at $Proxy1.insertWorkFlow(Unknown Source)
	at
com.ccs.cco.cms.rcts.client.calltracking.CallTrackingRemotingDelegate.in
sertWorkFlow(CallTrackingRemotingDelegate.java:210)
	at Actions.action(Actions.java:2344)
25-Nov-2009:01:59:25.792	scd2nts044	main
PERFORMANCEMONITOR	ICallTrackingService.insertWorkFlow
ClientId=test_2009.9.1.006 insertWorkFlow call.
ltu068_scd2nts044_-77fec0ce:125299ecace:-7e72	60078




=======
= Server log - Shows that the response took 7ms to send back out
=======

RetentionCallTrackingServiceFile123.log:25-Nov-2009:06:58:27.091
pfwls3  ExecuteThread: '32' for queue: 'default'
PERFORMANCEMONITOR      CallTrackingCore.insertWorkFlow
ClientId=test_2009.9.1.006 insertWorkFlow call.
ltu068_scd2nts044_-77fec0ce:125299ecace:-7e72   7
This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law.  If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED.  Although this transmission and
any attachments are believed to be free of any virus or other
defect that might affect any computer system into which it is
received and opened, it is the responsibility of the recipient to
ensure that it is virus free and no responsibility is accepted by
JPMorgan Chase & Co., its subsidiaries and affiliates, as
applicable, for any loss or damage arising in any way from its use.
 If you received this transmission in error, please immediately
contact the sender and destroy the material in its entirety,
whether in electronic or hard copy format. Thank you.

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

HttpClient blocks forever sometimes when open a HTTPS connection

2009-11-25T11:13:23Z


Hi all,

I'm using HTTPClient together with Axis 2. My threads executes thousands of
calls to webservices per day. Sometimes those threads blocks forever, none
of the timeouts are executed and I need to restart the application. I have
researched everything in the net but I can't found a solution.

I put the logs in TRACE mode. The last log message when a thread became
blocked is always the same:

DEBUG org.apache.commons.httpclient.HttpConnection - Open connection to
xxx.xxx.xxx.xxx:443

The next message should be:

TRACE org.apache.commons.httpclient.HttpMethodBase - enter
HttpMethodBase.execute(HttpState, HttpConnection)

Which blocking operations are doing between this two points?

I have one MultiThreadedHttpConnectionManager and one HTTPClient shared
between all the threads.

I setup it using this code:

        HttpConnectionManagerParams cmparams = new
HttpConnectionManagerParams();
        cmparams.setSoTimeout(timeout);
        cmparams.setDefaultMaxConnectionsPerHost(100);
        cmparams.setMaxTotalConnections(500);
        cmparams.setConnectionTimeout(timeout);
        cmparams.setTcpNoDelay(true);

        HttpClientParams params = new HttpClientParams();
        params.setSoTimeout(timeout);
        params.setConnectionManagerTimeout(timeout);

        conmgr = new MultiThreadedHttpConnectionManager();
        conmgr.setParams(cmparams);

        httpClient = new HttpClient(params, conmgr);

What you suggested to resolve this problem? 

Thanks,
Diego Patricio


-- 
View this message in context: http://old.nabble.com/HttpClient-blocks-forever-sometimes-when-open-a-HTTPS-connection-tp26510963p26510963.html
Sent from the HttpClient-User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

Re: Using one HttpClient between many threads

2009-11-24T14:01:26Z


On Nov 24, 2009, at 5:23am, H�kon Sagehaug wrote:

> Hi all,
>
> I've got a web service that pulls files for different sources, among  
> http,
> and I huse HttpClient for this, so my question is. If I create  a  
> Httpclient
> from ThreadSafeClientConnManager, can I then have one  
> instance(static) of
> HttpClient that is shared between the instances of the web service.  
> So I can
> save some resources and also not creating a new HttpClient for each  
> request.

Yes, that's correct.

Note that by default the ThreadSafeClientConnManager has a limit of 20  
simultaneous connections, so you might need to increase that limit.

-- Ken

PS - See http://hc.apache.org/httpcomponents-client/tutorial/html/ for  
lots of useful info, especially http://hc.apache.org/httpcomponents-client/tutorial/html/connmgmt.html#d4e629


> cheers, H�kon
> -- 
> H�kon Sagehaug, Scientific Programmer
> Parallab, Bergen Center for Computational Science (BCCS)
> UNIFOB AS (University of Bergen Research Company)
> Hakon.Sagehaug@bccs.uib.no, phone +47 55584125

--------------------------------------------
Ken Krugler
+1 530-210-6378
http://bixolabs.com
e l a s t i c   w e b   m i n i n g





---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org