Re: HTTP Version Not Supported Error

[Michael Becke]

Hi Nick,
Sounds like there may be a problem with the server side.  What server 
are you using?

Mike
On Oct 19, 2004, at 6:04 PM, Nick Jarvis wrote:
Mike,
I have taken your advise and set the content length manually sending 
in the length of a file even if it is larger than 2 gigs.  I am 
getting a bug however when uploading over 2 gigs still.  It seems that 
the server is blocking the read function for the ServletInputStream.  
I get a socket read time out exception thrown.  When I look at the 
bytes that were written and the length of the file, the bytes that 
were written seem to be more than the length of the file.  This only 
occurs for files over 2 gigs.  I tested multiple files, (512 MB, 1.8 
GB, 2.0 GB).  On the client side I have checked my code for the file 
input stream and writing of the bytes to the request output stream.  
The bytes I am writing are consistent with the length of the file, yet 
I am having this trouble on the server side.  I am using HttpServlet 
on the server side of my application.  I am getting the input stream 
from the request input stream, I am creating a file output stream, and 
I am writing to the file.  I believe that the HttpServlet should be 
compatible with HTTP 1.1.  Still, from my previous threading problem I 
had to set the setHttp11 function to false so that I do not get the 
upload error I stated before.  Sorry for the questions, but I have 
tried fixing this and understanding it to no avail.  I appreciate any 
help that you could give me.  Thanks for your time,

N. Jarvis
From: Michael Becke [EMAIL PROTECTED]
Reply-To: Commons HttpClient Project 
[EMAIL PROTECTED]
To: Commons HttpClient Project 
[EMAIL PROTECTED]
Subject: Re: HTTP Version Not Supported Error
Date: Mon, 18 Oct 2004 11:10:48 -0400

Hi Nick,
I have one addition to Roland's comments.
b) Don't call setContentLength, or set it to -1 in a
FilePart object. This should work fine with HTTP/1.1
and chunked encoding, but also with HTTP/1.0 and
no chunked encoding. Since the server does not know
the content length in advance, it has to read until the
end of the stream in no-chunks mode. Connection
re-use is impossible, but after transferring more than
2 gigs I doubt you'll notice the performance impact
of opening a new connection :-)
It might be a violation of HTTP to POST data without
a valid content length, but since you're controlling
the server as well, that shouldn't bother you much.
The HttpClient 2.0 API does not directly support setting content 
length  2GB because of the use of an int.  This has been fixed in 
the 3.0 API but it can be done in 2.0 by setting the content-length 
header manually:

method.setRequestHeader(Content-Length, Some number bigger than 
2GB);

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

_
FREE pop-up blocking with the new MSN Toolbar – get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

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


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

Re: HTTP Version Not Supported Error

[Michael Becke]

Hi Nick,
I have one addition to Roland's comments.
b) Don't call setContentLength, or set it to -1 in a
FilePart object. This should work fine with HTTP/1.1
and chunked encoding, but also with HTTP/1.0 and
no chunked encoding. Since the server does not know
the content length in advance, it has to read until the
end of the stream in no-chunks mode. Connection
re-use is impossible, but after transferring more than
2 gigs I doubt you'll notice the performance impact
of opening a new connection :-)
It might be a violation of HTTP to POST data without
a valid content length, but since you're controlling
the server as well, that shouldn't bother you much.
The HttpClient 2.0 API does not directly support setting content length 
 2GB because of the use of an int.  This has been fixed in the 3.0 API 
but it can be done in 2.0 by setting the content-length header manually:

method.setRequestHeader(Content-Length, Some number bigger than 2GB);
Mike
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invalid response tests

[Michael Becke]

Ah, I see.  Thanks for the pointer.
Mike
On Oct 12, 2004, at 5:44 AM, Oleg Kalnichevski wrote:
On Tue, 2004-10-12 at 04:04, Michael Becke wrote:
Hello All,
I've been starting to refactor some of the webapp test and have come
upon a bit of a problem.  I'm not terribly familiar with the
SimpleHttpServer setup so perhaps there is simple solution that is
eluding me.  The problem is that sending invalid responses can be  
quite
difficult.  Specifically I'm trying to send a response with content  
but
no content length.  Is there an easy way to do this?

Mike
Mike,
HttpRequestHandler provides direct access to  
SimpleHttpServerConnection,
which should be sufficient to simulate pretty much any type of  
malformed
responses:

http://jakarta.apache.org/commons/httpclient/3.0/xref-test/org/apache/ 
commons/httpclient/server/HttpRequestHandler.html

You may want to take a look at TestBadContentLength as an example of
using HttpRequestHandler
http://jakarta.apache.org/commons/httpclient/3.0/xref-test/org/apache/ 
commons/httpclient/TestBadContentLength.html

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


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

Re: [ANNOUNCE] HttpClient is now a separate project in [Bugzilla] issue tracking system

[Michael Becke]

Awesome!  Nice work Oleg.
Mike
Oleg Kalnichevski wrote:
HttpClient project has taken a very important step toward becoming a
full-fledged Jakarta level project. From today, HttpClient is a separate
project in Apache Bugzilla issue tracking system. It is no longer a
component of the Commons project. Please use the following details when
filing bug reports for 2.0 and 3.0 branches of HttpClient: 

Product: HttpClient
Component: Commons HttpClient
Use the following URL for convenience:
http://issues.apache.org/bugzilla/enter_bug.cgi?product=HttpClient
All the existing issues, closed and open, are still available under
their usual URLs.
With HttpClient being a separate project in Bugzilla we will be able to
define release versions and target milestones independently from Jakarta
Commons 

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

Re: [Bugzilla] vs [JIRA] revisited

[Michael Becke]

I agree this makes sense. I am not sure, though, whether we can
reasonably expect things to happen in one 'Big Bang': mailing lists, 
new
CVS repository, web site, JIRA migration and so on. Most likely not.
Another question is if we want to switch to Subversion when we go to 
4.0.  It sounds like Jakarta is moving in that direction.  Also, if 
we're going to switch repos and change our package name it would seem 
like a good time.

I agree that it may be difficult to do all these things at once, but I 
think if we start doing things now it shouldn't be too painful.  The 
next item to move is probably the mailing list.  This has been on my 
TODO list for a while now.  I'll email infrastructure tonight and get 
the ball rolling.

Besides, unless we start getting MASSIVELY more feedback on 3.0, I am
not sure what else we can do but start hacking on 4.0 branch while 3.0
still goes through its natural development cycle: alpha - beta - rc 
-
release. I sense the work on 4.0 may well commence as early as next
month. Basically that will buy us some time, but not much. I certainly
want to start the discussion on the 4.0 architecture (at least in broad
strokes) very, very soon.
Next month seems pretty soon, but I guess you never know.  My guess was 
that it wouldn't happen until January.  We definitely want a pretty 
solid plan before we get started though.

This, again, makes the issue of issue tracking system highly important,
as we better have a sane road map and reasonably well articulated
strategy as soon as people start asking what the heck Jakarta 
HttpClient
4.0 is all about and how on earth we ended up with 3 API incompatible
branches.
Yes, I'm not looking forward to 3 supported APIs at the same time.  
Hopefully 2.0 will be mostly frozen by the time 4.0 gets started.

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

Invalid response tests

[Michael Becke]

Hello All,
I've been starting to refactor some of the webapp test and have come 
upon a bit of a problem.  I'm not terribly familiar with the 
SimpleHttpServer setup so perhaps there is simple solution that is 
eluding me.  The problem is that sending invalid responses can be quite 
difficult.  Specifically I'm trying to send a response with content but 
no content length.  Is there an easy way to do this?

Mike 

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

[ANNOUNCE] Release of Commons HttpClient 2.0.2

[Michael Becke]

The Jakarta Commons team is pleased to announce the release of 
HttpClient 2.0.2. This release greatly improves the performance of 
executing methods where the response contains little or no content.  
Please visit the HttpClient 2.0 web site 
http://jakarta.apache.org/commons/httpclient/ for more information on 
HttpClient and this release.

Thank you,
Commons HttpClient Development Team
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: getting through a proxy server

[Michael Becke]

Hi Madeleine,
The first request fails because the credentials are not sent on the 
first method execution.  This is for two reasons.  One, because the 
proxy credentials have been specified with a particular realm. 
HttpClient does not know that a URL is protected by a particular realm 
until is tries and fails.  Also, HttpClient by default does not include 
credentials in requests except when challenged or when preemptive 
authentication has been turned on.  You should be able to fix this 
problem by doing the following:

// use a null realm
client.getState().setProxyCredentials(null, cache.ru.ac.za, creds);
// enable preemptive authentication
client.getState().setAuthenticationPreemptive(true);
Mike
Madeleine Wright wrote:
Hi.
Thanks for all the suggestions.  I tried replacing 
client.getHostConfiguration()..with method.getHostConfiguration butit 
didn't seem to make any difference.  I changed method back to client 
and retried and for the second attempt it did authenticate me - but not 
for the first.
Initially I had this:
retryhandler.setRetryCount(3);
but then I changed the 3 to 1.  Again the first try was refused but 
the second got through.

What I would like to understand is which host configuration is being 
accessed by client.getHostConfiguration().., the proxy host, the 
ultimate destination or me??

I was using a logger - and I'm appending the output with the retry at 
1 (not that it's any shorter!).  Is there something in the order of 
the code that causes a refusal the first time around that gets fixed the 
second time?  Currently my code (comments stripped out) looks like this:

public class MyHttpClient {
 private static String url = http://www.uct.ac.za/;;
 public static void main(String[] args) {
   HttpClient client = new HttpClient();
   GetMethod method = new GetMethod(url);
   client.getHostConfiguration().setProxy(, );
   Credentials creds = new UsernamePasswordCredentials(, );
   client.getState().setProxyCredentials(, cache.ru.ac.za, creds);
 Logger logger = Logger.getLogger(MyHttpClient.class);
   BasicConfigurator.configure();
   logger.info(Entering application.);
 DefaultMethodRetryHandler retryhandler = new 
DefaultMethodRetryHandler();
   retryhandler.setRequestSentRetryEnabled(false);
   retryhandler.setRetryCount(1);
   method.setMethodRetryHandler(retryhandler);

   try {
 int statusCode = client.executeMethod(method);
 if (statusCode != HttpStatus.SC_OK) {
   System.err.println(Method failed:  + method.getStatusLine());
 }
 byte[] responseBody = method.getResponseBody();
 System.out.println(new String(responseBody));
   } catch (IOException e) {
 System.err.println(Failed to download file.);
 e.printStackTrace();
   } finally {
 method.releaseConnection();
   }
 }
}
The error log follows.
Thanks so much.
Madeleine
468 [main] INFO MyHttpClient  - Entering application.
484 [main] DEBUG org.apache.commons.httpclient.HttpClient  - enter 
HttpClient.executeMethod(HttpMethod)
484 [main] DEBUG org.apache.commons.httpclient.HttpClient  - enter 
HttpClient.executeMethod(HostConfiguration,HttpMethod,HttpState)
515 [main] DEBUG org.apache.commons.httpclient.HttpConnection  - enter 
HttpConnection.open()
547 [main] DEBUG org.apache.commons.httpclient.HttpConnection  - 
HttpConnection.setSoTimeout(0)
547 [main] DEBUG org.apache.commons.httpclient.HttpMethodBase  - enter 
HttpMethodBase.execute(HttpState, HttpConnection)
547 [main] DEBUG org.apache.commons.httpclient.HttpMethodBase  - Execute 
loop try 1
547 [main] DEBUG org.apache.commons.httpclient.HttpMethodBase  - enter 
HttpMethodBase.processRequest(HttpState, HttpConnection)
547 [main] DEBUG org.apache.commons.httpclient.HttpMethodBase  - Attempt 
number 1 to process request
547 [main] DEBUG org.apache.commons.httpclient.HttpMethodBase  - enter 
HttpMethodBase.writeRequest(HttpState, HttpConnection)
547 [main] DEBUG org.apache.commons.httpclient.HttpMethodBase  - enter 
HttpMethodBase.writeRequestLine(HttpState, HttpConnection)
547 [main] DEBUG org.apache.commons.httpclient.HttpMethodBase  - enter 
HttpMethodBase.generateRequestLine(HttpConnection, String, String, 
String, String)
562 [main] DEBUG httpclient.wire.header  -  GET http://www.uct.ac.za/ 
HTTP/1.1[\r][\n]
562 [main] DEBUG org.apache.commons.httpclient.HttpConnection  - enter 
HttpConnection.print(String)
578 [main] DEBUG org.apache.commons.httpclient.HttpConnection  - enter 
HttpConnection.write(byte[])
578 [main] DEBUG org.apache.commons.httpclient.HttpConnection  - enter 
HttpConnection.write(byte[], int, int)
578 [main] DEBUG org.apache.commons.httpclient.HttpMethodBase  - enter 
HttpMethodBase.writeRequestHeaders(HttpState,HttpConnection)
578 [main] DEBUG org.apache.commons.httpclient.HttpMethodBase  - enter 
HttpMethodBase.addRequestHeaders(HttpState, HttpConnection)
578 [main] DEBUG org.apache.commons.httpclient.HttpMethodBase  - enter 
HttpMethodBase.addUserAgentRequestHeaders(HttpState, 

Re: getting through a proxy server

[Michael Becke]

Also, preemptive authentication is covered in more detail at 
http://jakarta.apache.org/commons/httpclient/authentication.html.

Mike
Madeleine Wright wrote:
Hi.
Thanks for all the suggestions.  I tried replacing 
client.getHostConfiguration()..with method.getHostConfiguration butit 
didn't seem to make any difference.  I changed method back to client 
and retried and for the second attempt it did authenticate me - but not 
for the first.
Initially I had this:
retryhandler.setRetryCount(3);
but then I changed the 3 to 1.  Again the first try was refused but 
the second got through.

What I would like to understand is which host configuration is being 
accessed by client.getHostConfiguration().., the proxy host, the 
ultimate destination or me??

I was using a logger - and I'm appending the output with the retry at 
1 (not that it's any shorter!).  Is there something in the order of 
the code that causes a refusal the first time around that gets fixed the 
second time?  Currently my code (comments stripped out) looks like this:

public class MyHttpClient {
 private static String url = http://www.uct.ac.za/;;
 public static void main(String[] args) {
   HttpClient client = new HttpClient();
   GetMethod method = new GetMethod(url);
   client.getHostConfiguration().setProxy(, );
   Credentials creds = new UsernamePasswordCredentials(, );
   client.getState().setProxyCredentials(, cache.ru.ac.za, creds);
 Logger logger = Logger.getLogger(MyHttpClient.class);
   BasicConfigurator.configure();
   logger.info(Entering application.);
 DefaultMethodRetryHandler retryhandler = new 
DefaultMethodRetryHandler();
   retryhandler.setRequestSentRetryEnabled(false);
   retryhandler.setRetryCount(1);
   method.setMethodRetryHandler(retryhandler);

   try {
 int statusCode = client.executeMethod(method);
 if (statusCode != HttpStatus.SC_OK) {
   System.err.println(Method failed:  + method.getStatusLine());
 }
 byte[] responseBody = method.getResponseBody();
 System.out.println(new String(responseBody));
   } catch (IOException e) {
 System.err.println(Failed to download file.);
 e.printStackTrace();
   } finally {
 method.releaseConnection();
   }
 }
}
The error log follows.
Thanks so much.
Madeleine
468 [main] INFO MyHttpClient  - Entering application.
484 [main] DEBUG org.apache.commons.httpclient.HttpClient  - enter 
HttpClient.executeMethod(HttpMethod)
484 [main] DEBUG org.apache.commons.httpclient.HttpClient  - enter 
HttpClient.executeMethod(HostConfiguration,HttpMethod,HttpState)
515 [main] DEBUG org.apache.commons.httpclient.HttpConnection  - enter 
HttpConnection.open()
547 [main] DEBUG org.apache.commons.httpclient.HttpConnection  - 
HttpConnection.setSoTimeout(0)
547 [main] DEBUG org.apache.commons.httpclient.HttpMethodBase  - enter 
HttpMethodBase.execute(HttpState, HttpConnection)
547 [main] DEBUG org.apache.commons.httpclient.HttpMethodBase  - Execute 
loop try 1
547 [main] DEBUG org.apache.commons.httpclient.HttpMethodBase  - enter 
HttpMethodBase.processRequest(HttpState, HttpConnection)
547 [main] DEBUG org.apache.commons.httpclient.HttpMethodBase  - Attempt 
number 1 to process request
547 [main] DEBUG org.apache.commons.httpclient.HttpMethodBase  - enter 
HttpMethodBase.writeRequest(HttpState, HttpConnection)
547 [main] DEBUG org.apache.commons.httpclient.HttpMethodBase  - enter 
HttpMethodBase.writeRequestLine(HttpState, HttpConnection)
547 [main] DEBUG org.apache.commons.httpclient.HttpMethodBase  - enter 
HttpMethodBase.generateRequestLine(HttpConnection, String, String, 
String, String)
562 [main] DEBUG httpclient.wire.header  -  GET http://www.uct.ac.za/ 
HTTP/1.1[\r][\n]
562 [main] DEBUG org.apache.commons.httpclient.HttpConnection  - enter 
HttpConnection.print(String)
578 [main] DEBUG org.apache.commons.httpclient.HttpConnection  - enter 
HttpConnection.write(byte[])
578 [main] DEBUG org.apache.commons.httpclient.HttpConnection  - enter 
HttpConnection.write(byte[], int, int)
578 [main] DEBUG org.apache.commons.httpclient.HttpMethodBase  - enter 
HttpMethodBase.writeRequestHeaders(HttpState,HttpConnection)
578 [main] DEBUG org.apache.commons.httpclient.HttpMethodBase  - enter 
HttpMethodBase.addRequestHeaders(HttpState, HttpConnection)
578 [main] DEBUG org.apache.commons.httpclient.HttpMethodBase  - enter 
HttpMethodBase.addUserAgentRequestHeaders(HttpState, HttpConnection)
578 [main] DEBUG org.apache.commons.httpclient.HttpMethodBase  - enter 
HttpMethodBase.addHostRequestHeader(HttpState, HttpConnection)
578 [main] DEBUG org.apache.commons.httpclient.HttpMethodBase  - Adding 
Host request header
578 [main] DEBUG org.apache.commons.httpclient.HttpMethodBase  - enter 
HttpMethodBase.addCookieRequestHeader(HttpState, HttpConnection)
593 [main] DEBUG org.apache.commons.httpclient.HttpState  - enter 
HttpState.getCookies()
593 [main] DEBUG org.apache.commons.httpclient.cookie.CookieSpec  - 
enter CookieSpecBase.match(String, int, 

[VOTE][RESULT] 2.0.2 release

[Michael Becke]

With 2 +1 votes and 2 +0 votes we'll have a 2.0.2 release shortly.
I should be able to work on the release this weekend.  Please let me  
know if anyone has some time to help out.

Mike
Vote summary:
Binding -
+1 Michael Becke - mbecke at apache
+1 Oleg Kalnichevski - olegk at apache
+0 Dion Gillard - dion at apache
Non-binding -
+0 Eric Yuzwa - Erik.Yuzwa at encana.com
http://nagoya.apache.org/eyebrowse/BrowseList?listName=commons- 
[EMAIL PROTECTED]by=threadfrom=892622

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

Re: Mutithread use of HttpClient

[Michael Becke]

Hello Clement,
HttpClient is not thread-safe by default, but fortunately it's quite  
easy to make it so.  Please have a look at the threading guide for some  
more info  
http://jakarta.apache.org/commons/httpclient/threading.html.

Mike
On Oct 6, 2004, at 5:36 PM, Clement Soullard wrote:
Hello,
I am using http client to program a proxy that record my requests into  
an XML file. For this I use http client to submit the requests to the  
server (Tomcat 5.0.18).
Http Client is used in a multi thread way so I can keep the session  
information in my client.

But I get two kind of error : IlleggalStateException, and IOException.  
Those error does not occurs when I write synchronize before the  
executeMethode that make me think this is a bug of HttpClient in  
multithreaded mode.

In summary, I get :
Unable to parse header: HTTP/1.1 200 OK
-  that seems strange to me
java.lang.IllegalStateException: Connection is not open
- The static locks and instances are so intricated that I have  
absolutely have no idea what causes such errors.

And also :
The server localhost failed to respond with a valid HTTP response
- That could be explained if my server was on an heavy load, but I am  
single user of the proxy so I know this is not enought to put down my  
server down.

Finally, it seems that the synchronize keyword before my executeMethod  
doesn't make the HttpClient so slow but it works well in that mode.

Here, are three types of stacktraces that occurs :
org.apache.commons.httpclient.ProtocolException: The server localhost  
failed to respond with a valid HTTP response
   at  
org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodB 
ase.java:1838)
   at  
org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBas 
e.java:1587)
   at  
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.jav 
a:998)
   at  
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpM 
ethodDirector.java:392)
   at  
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMeth 
odDirector.java:178)
   at  
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java: 
392)
   at  
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java: 
324)
   at  
proxy.server.RequestHandlerHttpClient.processRequest(RequestHandlerHttp 
Client.java:160)
   at  
proxy.server.RequestHandlerHttpClient.run(RequestHandlerHttpClient.java 
:79)
   at java.lang.Thread.run(Unknown Source)

GRAVE:  
http://us.update.companion.yahoo.com/slv/v4/ 
2.html?.pc=.a=0.ta=cgnone,ccnone,cius,cv5_3_12,cp.cv=1.cs=b,c94c6ba 
69c94d410,p,448d7c721d9dddabt=6313000: 
org.apache.commons.httpclient.ProtocolException: Unable to parse  
header: HTTP/1.1 200 OK
org.apache.commons.httpclient.ProtocolException: Unable to parse  
header: HTTP/1.1 200 OK
   at  
org.apache.commons.httpclient.HttpParser.parseHeaders(HttpParser.java: 
189)
   at  
org.apache.commons.httpclient.HttpMethodBase.readResponseHeaders(HttpMe 
thodBase.java:1782)
   at  
org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBas 
e.java:1589)
   at  
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.jav 
a:998)
   at  
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpM 
ethodDirector.java:392)
   at  
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMeth 
odDirector.java:178)
   at  
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java: 
392)
   at  
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java: 
324)
   at  
proxy.server.RequestHandlerHttpClient.processRequest(RequestHandlerHttp 
Client.java:160)
   at  
proxy.server.RequestHandlerHttpClient.run(RequestHandlerHttpClient.java 
:79)
   at java.lang.Thread.run(Unknown Source)

GRAVE:  
http://us.update.companion.yahoo.com/slv/v4/ 
2.html?.pc=.a=0.ta=cgnone,ccnone,cius,cv5_3_12,cp.cv=1.cs=b,c94c6ba 
69c94d410,p,448d7c721d9dddabt=6132640: 
java.lang.IllegalStateException: Connection is not open
java.lang.IllegalStateException: Connection is not open
   at  
org.apache.commons.httpclient.HttpConnection.assertOpen(HttpConnection. 
java:1244)
   at  
org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.ja 
va:1092)
   at  
org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodB 
ase.java:1824)
   at  
org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBas 
e.java:1587)
   at  
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.jav 
a:998)
   at  
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpM 
ethodDirector.java:392)
   at  
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMeth 
odDirector.java:178)
   at  
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java: 
392)
   at  
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java: 
324)
   at  
proxy.server.RequestHandlerHttpClient.processRequest(RequestHandlerHttp 

Re: [VOTE] 2.0.2 release

[Michael Becke]

Sounds like you're ready for a release :)  I'll call for a vote again 
in a moment.

Mike
On Oct 5, 2004, at 6:33 PM, Eric Johnson wrote:
Am I mistaken, or have the recent issues been dealt with?
-Eric.
Michael Becke wrote:
Looks like 2.0.2 has been cancelled for the moment. I'll call for a 
vote again after we fix the recently discovered issues.

Mike
On Sep 29, 2004, at 11:05 AM, Michael Becke wrote:
-
To unsubscribe, e-mail: 
[EMAIL PROTECTED]
For additional commands, e-mail: 
[EMAIL PROTECTED]


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

Re: [VOTE] 2.0.2 release

[Michael Becke]

+1
Also I'm counting +1 for Odi as per his email when he left for vacation.
Mike
On Oct 5, 2004, at 9:48 PM, Michael Becke wrote:
After a little delay...  I propose that we mark the latest code in CVS  
HTTPCLIENT_2_0 as 2.0.2  and proceed with a release.  Please vote as  
follows:
--- 
---
 Vote:  HttpClient 2.0.2 release
 [ ] +1 I am in favor of the release, and will help support it.
 [ ] +0 I am in favor of the release, but am unable to help support it.
 [ ] -0 I am not in favor of the release.
 [ ] -1 I am against this proposal (must include a reason).
   
--- 
---

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


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

Re: Unlocatable exception withinhttpclient.HttpRecoverableException

[Michael Becke]

Hi Jeff,
Is it possible that you're using the same HttpConnection from more than  
one thread/method?  Is the same SimpleHttpConnectionManager being  
shared?

If not I would suggest disabling connection reuse.  This can usually be  
done by setting the following header on each method.

method.setRequestHeader(Connection, close);
Mike
On Oct 5, 2004, at 6:05 PM, Jeff Fern wrote:
Hello,
Thank-you for your reply.  I do not believe that the errors can be  
caused
due to the server being overloaded - it is my desktop machine and the  
only
person accessing the web server is myself. Additionally, the machine  
is not
doing anything intensive (just running X, firefox and eclipse), it is  
an
Athlon 2800+ with 512MB RAM.

The fact that I also get a socket closed message as well as unable to  
find
line starting with HTTP is also confusing me :/

Regards,
-Jeff Fern
-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: 05 October 2004 13:51
To: Commons HttpClient Project
Cc: Jeff Fern
Subject: Re: Unlocatable exception  
withinhttpclient.HttpRecoverableException

Jeff,
Sometimes, usually when under heavy load, the web server may be able to
receive requests but unable to process them due to low resources (most
commonly worker threads). In such a case the web server may simply  
have no
other choice but to drop the connection without sending back any status
code. This in turn causes HttpClient to throw a  
HttpRecoverableException
unable to find line starting with HTTP

Can it be that you have been stressing the server a bit too much?
Anyways, usually unable to find line starting with HTTP exception  
is not
a HttpClient fault, but that of the target server. The regrettable  
thing
about it it is a poor choice of exception class name and a misleading  
error
message. (This problem has already been fixed in HttpClient 3.0)

Hope this helps a little
Oleg
On Tue, 2004-10-05 at 08:27, Jeff Fern wrote:
Hello all,
I am running Tomcat 5.0.27 with Java 1.4.2 on my local machine (Debian
sarge). I have a Java webapp running on Tomcat, which outputs XML and
I am using Cocoon 2.1 to style the XML with a static XSLT stylesheet
to generate HTML.
I have managed to generate an bug which occurs about 80% of the time.
When I submit a form, cocoon generates one of a couple of errors:
org.apache.cocoon.ProcessingException: There is a problem with the  
URI:

http://127.0.0.1:8080/Conference/GetConference?conferenceName=UbiComp
%20200
5
http://127.0.0.1:8080/Conference/GetConference?conferenceName=UbiComp%
202005
:
org.apache.commons.httpclient.HttpRecoverableException:
org.apache.commons.httpclient.HttpRecoverableException: Error in
parsing the status line from the response: unable to find line  
starting
with HTTP
or org.apache.cocoon.ProcessingException: There is a problem with the
URI:  http://127.0.0.1:8080/Conference/AddDetails
http://127.0.0.1:8080/Conference/AddDetails:
org.apache.commons.httpclient.HttpRecoverableException:
java.net.SocketException: Socket closed
Trying to re-submit the same information sometimes displays the
correct results, sometimes generates an error.
I have enabled logging with log4j using the examples at
http://jakarta.apache.org/commons/httpclient/logging.html
http://jakarta.apache.org/commons/httpclient/logging.html The only
ouput generated in the log file is:
- Recoverable exception caught when processing request
- Recoverable exception caught but MethodRetryHandler.retryMethod()
returned false, rethrowing exception
I have also tried my code on Tomcat 5.5 with Java 1.5 and get the
exact same results.
I am unable to locate any piece of my code that causes this error.
Any help or suggestions would be much appreciated,
Regards,




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

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


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

Re: GetMethod instantiation throwing exception?

[Michael Becke]

Hi Erik,
HttpClient 3.0 has added a dependency for commons-codec.  Adding this to 
your classpath should fix the problem.

Mike
Yuzwa, Erik wrote:
Hi all,
 
I'm trying to get HttpClient working alongside NTLM authentication to
automagically grab some XML data for users.
 
The docs are fairly clear on using HttpClient with NTLM, however my
GetMethod instantiation regularly blows up throwing a 
java.lang.NoClassDefFoundError: org/apache/commons/codec/DecoderException
 
//begin-code snippet
 
//according to HttpClient docs, run this code before using NTLM...
String secProviderName = com.sun.crypto.provider.SunJCE;
java.security.Provider secProvider =
(java.security.Provider)Class.forName(secProviderName).newInstance();
Security.addProvider(secProvider);
 
HttpClient client = new HttpClient();

//grabbing server names from a file to do the requestin'
String sUrl= http://; + sServer + /onenet/xtier-login; //DOES build
valid URLs
 
client.getState().setCredentials(
 AuthScope.ANY,
 new NTCredentials(sUser, sPass, sServer, stovokor.com)
 );
 
GetMethod http_get = new GetMethod( sUrl ); //wammo! Here's the offender

//end-code snippet
 
There's no documentation with the GetMethod object concerning any exceptions
thrown during instantiation, so I'm stuck
trying to figure out what the hey is happening.
 
Thanks!

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

Re: Timeouts

[Michael Becke]

Hi Vijay,
Send timeout is not something that Java Sockets support natively, and 
as such has not been added to HttpClient.  It would be possible to 
implement this kind of functionality but it would require a second 
thread to poll the executing thread.  The HttpMethod.abort() method 
in HttpClient 3.0 could be particularly useful for this.

Do you have a particular use in mind?
Mike
On Oct 4, 2004, at 1:24 PM, Vijay wrote:
Sorry if this is a very basic question:
I would like to set 3 timeouts (connect, send and receive). I found
the following in HttpClient package.
HttpClient.setTimeout -- sets socket RECEIVE timeout
HttpClient.setConnectionTimeout -- sets socket CONNECT timeout
Is there any method available for setting socket SEND timeout?
Thanks
Vijay
-
To unsubscribe, e-mail: 
[EMAIL PROTECTED]
For additional commands, e-mail: 
[EMAIL PROTECTED]


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

Re: convert usage if URLConnection to HttpClient

[Michael Becke]

Hi Jason,
Please have a look at the HttpClient authentication guide  
http://jakarta.apache.org/commons/httpclient/authentication.html and  
the basic authentication example  
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/ 
examples/BasicAuthenticationExample.java? 
rev=1.1.2.3only_with_tag=HTTPCLIENT_2_0_BRANCH.  These should clear  
up any questions you may have.  Please let us know if you run into any  
trouble.

Mike
On Oct 2, 2004, at 2:16 PM, Jason Novotny wrote:
Hi,
   I had been using some crufty code using URLConnection to perform  
basic auth to retrieve the list of applications using the Tomcat  
manager webapp. I'd like to convert this to use  
commons-httpclient-2.0.1.

   It should be pretty simple I think-- what is required is to invoke  
http://127.0.0.1/manager?list performing basic authentication using  
name and password and then I get back a response which has a specific  
format.
   My current code is shown below and I'd like to know what the 3 or 5  
magic lines are to do the same thing using HttpClient.

   Thanks very much, Jason
try {
   String serverName = req.getServerName();
   int serverPort = req.getServerPort();
   URL u = new URL(http://; + serverName + : + serverPort +  
/manager + command);
   URLConnection con = u.openConnection();

   String up = USERNAME + : + PASSWORD;
   String encoding = null;
   // check to see if sun's Base64 encoder is available.
   try {
   sun.misc.BASE64Encoder encoder =
   (sun.misc.BASE64Encoder)

Class.forName(sun.misc.BASE64Encoder).newInstance();
   encoding = encoder.encode(up.getBytes());
   } catch (Exception ex) { // sun's base64 encoder isn't  
available
   throw new TomcatManagerException(No  
sun.misc.BASE64Encoder availoable in JDK!);
   }

   con.setRequestProperty(Authorization, Basic  +  
encoding);
   con.setDoInput(true);
   con.setUseCaches(false);
   con.connect();

   if (con instanceof HttpURLConnection) {
   HttpURLConnection httpConnection = (HttpURLConnection)  
con;
   // test for 401 result (HTTP only)
   if (httpConnection.getResponseCode() ==  
HttpURLConnection.HTTP_UNAUTHORIZED) {
   throw new TomcatManagerException(HTTP  
Authorization failure!);
   }
   }

   BufferedReader reader = new BufferedReader(new  
InputStreamReader(con.getInputStream()));

   // get first line
   // should be something like:
   // OK - some information text
   String line = null;
   line = reader.readLine();
   StringTokenizer tokenizer = new StringTokenizer(line, -);
   if (tokenizer.countTokens() == 2) {
   String rc = tokenizer.nextToken();
   String description = tokenizer.nextToken();
   result = new TomcatWebAppResult(rc, description);
   }
   while ((line = reader.readLine()) != null) {
   result.addWebAppDescriptor(line);
   }
   reader.close();
   } catch (IOException e) {
   throw new TomcatManagerException(Unable to perform  
command: , e);
   }

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


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

Re: java.lang.NoClassDefFoundError: org/apache/commons/codec/DecoderException

[Michael Becke]

Yes, commons-codec is a new dependency in HttpClient 3.0.
Mike
On Sep 30, 2004, at 11:22 PM, paul wrote:
gao, u need to put this jar into the classpath : commons-codec-1.2.jar
- Original Message -
From: gao maosen [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, September 30, 2004 6:53 PM
Subject: java.lang.NoClassDefFoundError:
org/apache/commons/codec/DecoderException

when i run the FormLoginDemo(login to
developer.java.sun.com)
it shows
java.lang.NoClassDefFoundError:
org/apache/commons/codec/DecoderException
at
org.apache.commons.httpclient.HttpMethodBase.init(HttpMethodBase.java 
:216)
at
org.apache.commons.httpclient.methods.GetMethod.init(GetMethod.java: 
88)
at FormLoginDemo.main(FormLoginDemo.java:33)
Exception in thread main

please tell me why ?thanks very much
_
Do You Yahoo!?

http://cn.rd.yahoo.com/mail_cn/tag/10m/*http://cn.mail.yahoo.com/ 
event/10m.html
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]


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


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

Re: threads problem with many connections

[Michael Becke]

Hello Guillaume,
Closing idle connections may also be of use.  This feature has been  
added in HttpClient 3.0alpha2 and the forthcoming HttpClient 2.0.2 via  
HttpConnectionManager.closeIdleConnections() and the  
o.a.c.httpclient.util.IdleConnectionTimeoutThread.

Mike
On Oct 1, 2004, at 6:57 AM, Guillaume Cottenceau wrote:
Hello,
We use HttpClient for performing several HTTP post in parallel in
our applications. We have a problem when the server(s) receiving
our HTTP post either answers very slowly, or goes mad and sends
garbage data over and over: the connection stays open forever,
but more important, the Java threads as well. We have situations
where we reach the maximum of Java threads our (tomcat)
application is configured to handle, and our whole application is
then unusable.
It seems that java.nio is capable of using only one thread for
several lowlevel (OS) socket connections, and is actually also
quite efficient.
I have seen that Oleg Kalnichevski has already expressed his
views several times on the subject, and I have seen that you want
to keep 1.2 compatibility, so java.nio out.
http://www.mail-archive.com/[EMAIL PROTECTED]/ 
msg05551.html
http://www.mail-archive.com/[EMAIL PROTECTED]/ 
msg06998.html

(btw, I don't agree with in my opinion there's absolutely
nothing that NIO can bring in in terms of performance to
client-side applications - well I agree that pure performance
is not the problem but threads and memory consumption surely is -
so in my opinion there is a lot to win with java.nio in
httpclient)
My question is, since you don't want to lose 1.2 compatibility
before 4.0, is there then a way to solve a typical too many
threads problem such as the one we have? Do you people never had
the same problem? Or have found a way to solve it?
It seems the HTTP protocol doesn't have anything resembling a
global timeout for a given connection (e.g. after x seconds,
close the receiving channel even if server hasn't finished
sending), and thus normally httpclient doesn't provide such a
thing. Do you think this should be investigated/implemented in
some way?
Thanks, and best regards.
--
Guillaume Cottenceau
-
To unsubscribe, e-mail:  
[EMAIL PROTECTED]
For additional commands, e-mail:  
[EMAIL PROTECTED]


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

[VOTE] 2.0.2 release

[Michael Becke]

I propose that we mark the latest code in CVS HTTPCLIENT_2_0 as 2.0.2  
and proceed with a release.  Please vote as follows:

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

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

Re: [VOTE] 2.0.2 release

[Michael Becke]

Looks like 2.0.2 has been cancelled for the moment. I'll call for a  
vote again after we fix the recently discovered issues.

Mike
On Sep 29, 2004, at 11:05 AM, Michael Becke wrote:
+1
Michael Becke wrote:
I propose that we mark the latest code in CVS HTTPCLIENT_2_0 as 2.0.2  
 and proceed with a release.  Please vote as follows:
-- 
-- --
 Vote:  HttpClient 2.0.2 release
 [ ] +1 I am in favor of the release, and will help support it.
 [ ] +0 I am in favor of the release, but am unable to help support  
it.
 [ ] -0 I am not in favor of the release.
 [ ] -1 I am against this proposal (must include a reason).
   
-- 
-- --
-
To unsubscribe, e-mail:  
[EMAIL PROTECTED]
For additional commands, e-mail:  
[EMAIL PROTECTED]
-
To unsubscribe, e-mail:  
[EMAIL PROTECTED]
For additional commands, e-mail:  
[EMAIL PROTECTED]


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

Re: ATTN Open-source projects using HttpClient

[Michael Becke]

Hi St.Ack,
Many thanks for taking the time to make such a detailed response.  I  
haven't had time to fully digest (no pun intended) your message, but  
I'll take a look at it again in the morning.  In the mean time I've  
added Heritrix to the applications page in CVS, which will be added to  
the site next time it's published.

Mike
On Sep 29, 2004, at 7:53 PM, stack wrote:
Oleg Kalnichevski wrote:
Thanks, Adam
Should we decide to go on a spamming spree, these may also become
potential victims ;-)

Let me preempt the spam (smile).
I'm part of the webgroup at the Internet Archive (archive.org).  We've  
been using httpclient at the heart of our open source crawler Heritrix  
(crawler.archive.org) for near on a year now (I've added on the end a  
submission for the httpclient applications page).  I've just upgraded  
HEAD to use 3.0alpha2 and was going to say a few words about the  
experience and how its running.

Heads up.  The following message is a little long.
The upgrade took way longer than I anticipated, a couple of days  
rather than a couple of hours.  While some of the time was spent on  
refactoring only slightly related to the httpcilent upgrade and  
testing to see all httpclient used features still work post upgrade,  
the bulk of the time was spent on redoing our auth system to fit the  
redesigned httpclient auth system. I had trouble figuring out how  
things work now in the absence of example. Our usage is a little  
out-of-the-ordinary in that we manage own store of credentials and  
manage when to load them onto a httpmethod.  Previous,  
HttpAuthenticator would select the scheme for me.  Now it seems like I  
have to do it myself using AuthChallengeParser and then iterate over  
the returns.  In general the new auth system changes look to be for  
the best.  It just cost time exploring.  Thereafter, the remainder was  
spent undoing our own custom retry to instead use a custom  
HttpMethodRetryHandler that is now part of httpclient core, study of  
the new configuration system to ensure correct usage, undoing old ways  
of specifying preferences, and exploiting new preference granularity  
particularly where it could make the crawler more robust  
(UNAMBIGUOUS_STATUS_LINE, STRICT_TRANSFER_ENCODING,  
STATUS_LINE_GARBAGE_LIMIT, etc).

With the new lib in place, we pass all of our little suite of  
selftests (includes Auth tests of logins and Basic and Digest Auth),  
and random broad crawling shows performance as comparable with the  
only weird exceptions having to do with timeouts on IBM SSL Sockets.  
Later I should have more detailed feedback on performance and  
robustness.

The IBM SSL socket timeout issues I'm seeing when I get an SSLSocket  
with a timeout (I set the timeout by getting a socket with the null  
arg constructor then doing an SSLSocket$connect with a timeout).  The  
exceptions do not happen when I use SUN JVM 1.4.2.  These are probably  
IBM JVM issues but I'll list them here anyways:

1. The IBM JVM 141 (cxia321411-20030930) NPEs setting the NoTcpDelay.   
Is anyone else seeing this?
java.lang.NullPointerException
   at com.ibm.jsse.bf.setTcpNoDelay(Unknown Source)
   at  
org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java: 
683)
   at  
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpCo 
nnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1328)

2. Using the IBM JVM 142, its saying SSL connection not open when we  
go to use inputstreams.
java.net.SocketException: Socket is not connected
   at java.net.Socket.getInputStream(Socket.java:726) at  
com.ibm.jsse.bs.getInputStream(Unknown Source)
   at  
org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java: 
715)
   at  
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpCo 
nnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1328)

By way of feedback on the 3.0 API, I'll describe the two places where  
the API is lacking regards our requirements forcing us to do yucky  
overlays.  First some context.  The crawler must record the response  
headers and response content exactly as it comes back over the wire  
and its supposed to be tenacious.

Regards recording exactly what the server sent us, we overlay  
HttpConnection with a version that wraps the socket input and output  
streams.  Here's the diff:

+// HERITRIX import.
+import org.archive.util.HttpRecorder;
+
/**
 * An abstraction of an HTTP [EMAIL PROTECTED] InputStream} and [EMAIL PROTECTED]  
OutputStream}
 * pair, together with the relevant attributes.
@@ -676,7 +679,6 @@
highly interactive environments, such as some client/server
situations. In such cases, nagling may be turned off  
through
use of the TCP_NODELAY sockets option. */
-
socket.setTcpNoDelay(this.params.getTcpNoDelay());
socket.setSoTimeout(this.params.getSoTimeout());

@@ -701,8 +703,23 @@
if (inbuffersize  2048) {
  

Re: ATTN Open-source projects using HttpClient

[Michael Becke]

I have no problem with posting to the dev lists for these other 
projects.  My feeling is that we should keep it friendly and just 
encourage people to have a look at 3.0 and then submit their 
requests/ideas to httpclient-dev or bugzilla.  Once we've done that I 
think we'll just have to be happy with the input we've had so far and 
move on.  There's only so much poking and prodding that we can do.

Mike
On Sep 28, 2004, at 12:09 PM, Oleg Kalnichevski wrote:
Folks, shall we try to approach members of the projects listed below
(except Slide) directly? Apparently no one of them is monitoring this
list.
How does everyone feel about it?
Oleg
On Mon, 2004-09-27 at 20:43, Oleg Kalnichevski wrote:
Sadly, no one seems to care. What do we do?
Oleg
On Mon, 2004-09-20 at 22:50, Oleg Kalnichevski wrote:
As far as I know the following projects rely on HttpClient 2.0 as a
required or optional dependency
* Apache Jakarta Slide (http://jakarta.apache.org/slide/)
* Apache Jakarta Cactus (http://jakarta.apache.org/cactus/)
* Apache Axis (http://ws.apache.org/axis/)
* Apache XML-RPC (http://ws.apache.org/xmlrpc/)
* Spring Framework (http://www.springframework.org/)
* HtmlUntit (http://htmlunit.sourceforge.net/)
* XINS (http://xins.sourceforge.net/)
I just wonder if any of the projects' committers are currently
subscribed to or monitor this mail list?
We would love to know if there are any plans to evaluate HttpClient 
3.0,
or any migration plans already. What can we do to make the 
transition,
if planned, easier?

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


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


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


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

Re: DO NOT REPLY [Bug 31378] - Move multipart request to a new RequestEntity type

[Michael Becke]

Works for me.
Mike
[EMAIL PROTECTED] wrote:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31378.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31378
Move multipart request to a new RequestEntity type


--- Additional Comments From [EMAIL PROTECTED]  2004-09-23 12:44 ---
Is the default content charset statically available anywhere else?

It's defined in the DefaultHttpParams these days. I would not like to see 
SimpleHttpServerConnection tightly coupled with DefaultHttpParams, though. In 
my opinion the SimpleHttpServerConnection should define its own 
DEFAULT_CONTENT_CHAR static variable. HttpConstants should be let quietly go 
away in the next release.

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

[VOTE][RESULT] HttpClient 3.0 alpha 2 release

[Michael Becke]

The vote has passed.  I will start working on a release, which should  
be ready by the end of the weekend.

Mike
Binding Votes: +1(3), +0(1)
+1 Michael Becke - mbecke -at- apache.org
+0 Dion Gillard - dion -at- apache.org
+1 Oleg Kalnichevski - olegk -at- apache.org
+1 Ortwin Glück - oglueck -at- apache.org
Non-binding Votes:  +1(2), +0(1)
+1 Paul - tjwee -at- fairex.com
+0 Tom Gerdes - TGerdes -at- OldRepublicTitle.com
+1 Ramesh Nethi mlists -at- imorph.com
Vote Thread:
http://nagoya.apache.org/eyebrowse/BrowseList?listName=commons- 
[EMAIL PROTECTED]by=threadfrom=885217

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

Re: HttpClient 3.0 is kind of done. Feedback needed

[Michael Becke]

I agree.  I think we're ready for another 3.0 release.
There has been surprisingly little comment on the 3.0 API, and I'm also  
concerned about freezing it until we've had more feedback.  We  
definitely have a chicken and the egg problem here.  My preference is  
to continue with a new 3.0 alpha release, and make a concerted effort  
to get it in front of people.

One area that we have been lacking is in promotion of 3.0 on the web  
site.  Currently the only mention of it is on the status page.  Perhaps  
we should make the 3.0 docs and javadocs available on the site, and try  
to reference them where possible from 2.0.  My feeling is that once  
people are aware of some of the 3.0 improvements they are willing to  
try it out, but unless they are HttpClient regulars they may not know  
it exists.

Come now Oleg.  You haven't been the Evil Comrade for some time now :)
Mike
On Sep 16, 2004, at 5:52 AM, Oleg Kalnichevski wrote:
Folks,
It looks like HttpClient 3.0 is not only ALPHA2 ready, it is almost  
code
and feature complete. There are only 5 open tickets targeted for 3.0
FINAL. It may take me just a couple of days to get all the remaining
issues dealt with, if needed.

http://nagoya.apache.org/bugzilla/buglist.cgi? 
bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemail1=emailtyp 
e1=substringemailassigned_to1=1email2=emailtype2=substringemailrepo 
rter2=1bugidtype=includebug_id=changedin=votes=chfieldfrom=chfiel 
dto=Nowchfieldvalue=product=Commonscomponent=HttpClienttarget_miles 
tone=3.0+Alpha+2target_milestone=3.0+Beta+1target_milestone=3.0+Beta+ 
2target_milestone=3.0+Finalshort_desc=short_desc_type=allwordssubstr 
long_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_ty 
pe=allwordssubstrkeywords=keywords_type=anywordsfield0-0 
-0=nooptype0-0-0=noopvalue0-0 
-0=cmdtype=doitnewqueryname=order=Reuse+same+sort+as+last+time

Unless we start getting considerably more feedback, HttpClient 3.0
development will stall completely.
I sense there are lots of folks who are not willing to port their code
from 2.0.x to 3.0 because the 3.0 branch is still considered unstable.
At the same time HttpClient 3.0 will stay there unless people start
porting.
I think it is really import to call an API freeze rather sooner than
later. That will enable to drop newer releases in place of older ones
and should give people enough confidence to start the transition from
2.0.x to 3.0. But before the API can be formally frozen I would really
like to hear some feedback from our users and peer open-source
developers. So far we have had virtually no feedback on the new API and
I am concerned that we may see an avalanche of change requests as soon
as we formally announce the API freeze and move closer to the first RC.
How does everyone feel about it?
Please share your ideas with me. I also have a few, but they all range
from 'ugly' to 'very ugly' and may involve my wearing my 'Evil Comrade'
hat and threatening people with some nasty stuff ;-)
Anyways, before things turn ugly, give us some feedback,  
pleeese

Oleg
*** 

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


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


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

[VOTE] 3.0 alpha 2 release

[Michael Becke]

It looks like we're ready for a 3.0 alpha 2 release.  Please vote as  
follows:

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

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

Re: [VOTE] 3.0 alpha 2 release

[Michael Becke]

+1
On Sep 16, 2004, at 10:12 PM, Michael Becke wrote:
It looks like we're ready for a 3.0 alpha 2 release.  Please vote as  
follows:

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

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


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

Re: HttpClient 3.0 is kind of done. Feedback needed

[Michael Becke]

Another evil plan that I have been contemplating recently is to address
our fellow open-source developers that are known to be using HttpClient
(read: shamelessly spam the dev mailing lists) and ask them what they
think of the new 3.0 API and whether they have any migration plans. If
needed I am prepared to put my kevlar helmet on with a shiny red star
and take all the blame for this atrocity.
I see no problem with this.  Sounds like a good idea.
Alternatively, we can simply let things develop as their natural pace
and start hacking on the 4.0 branch. Having three active development
branches may prove too daunting, though. So I would rather see the
HttpClient 3.0 brought to a logical conclusion and a stable release (be
it late BETA, RC or FINAL), deprecate HttpClient 2.0 and then move onto
the 4.0.
I think it's definitely too soon to make a move on 4.0.  I'd prefer to 
wait until 3.0 is nearly done, and then we can forget about 2.0.

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

Re: DO NOT REPLY [Bug 21329] - Add InputStream buffering.

[Michael Becke]

Hi Roland,
Yes, that was definitely part of the discussion, and this seems to be a 
pretty good solution for that.  Now that I've slept on it , I think 
this also came up when were originally discussing isStale() and how to 
determine if a connection is still valid.  Does buffering at this level 
cause problems here?  My gut reaction is that is that is could, but 
probably won't under most conditions.  My feeling is that there 
shouldn't be anything buffered between requests.  Does anyone have a 
good real-world test case for this?

Mike
On Sep 2, 2004, at 2:46 AM, [EMAIL PROTECTED] wrote:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=21329.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=21329
Add InputStream buffering.


--- Additional Comments From [EMAIL PROTECTED]  2004-09-02 06:46 
---
Hi Mike,

the discussion usually centered around buffering for the response body.
Since folks could just get the input stream and create their own 
buffered
stream on top, there didn't seem to be a need to create a buffered 
stream
within Http Client. (That's what I recall, I didn't check the 
archives.)

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


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

Re: DO NOT REPLY [Bug 21329] - Add InputStream buffering.

[Michael Becke]

Oleg,
Yes, I believe you are correct.  The potential is there for this to be 
an issue, but given how we currently handle requests I don't think it 
should even come up.  I'm +1 for the patch.

Mike
Oleg Kalnichevski wrote:
Mike,
I have been also thinking about repercussions on the reliability of the
stale connection check. I tend to conclude that with the existing
architecture (no HTTP pipelining support + response 'garbage' check)
there is virtually no chance of reading past the response body.
HttpClient always makes sure that 

(1) a new request can be executed over the same connection only after
the previous response has been consumed in its entirety
(2) drops the connection whenever it detects illegal content past the
declared response body 

Am I missing something?
Oleg
On Thu, 2004-09-02 at 14:23, Michael Becke wrote:
Hi Roland,
Yes, that was definitely part of the discussion, and this seems to be a 
pretty good solution for that.  Now that I've slept on it , I think 
this also came up when were originally discussing isStale() and how to 
determine if a connection is still valid.  Does buffering at this level 
cause problems here?  My gut reaction is that is that is could, but 
probably won't under most conditions.  My feeling is that there 
shouldn't be anything buffered between requests.  Does anyone have a 
good real-world test case for this?

Mike
On Sep 2, 2004, at 2:46 AM, [EMAIL PROTECTED] wrote:

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=21329.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=21329
Add InputStream buffering.


--- Additional Comments From [EMAIL PROTECTED]  2004-09-02 06:46 
---
Hi Mike,

the discussion usually centered around buffering for the response body.
Since folks could just get the input stream and create their own 
buffered
stream on top, there didn't seem to be a need to create a buffered 
stream
within Http Client. (That's what I recall, I didn't check the 
archives.)

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


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

Re: Problems with commons-logging jar and request for advice.

[Michael Becke]

I'm not sure it's really any better, but another option might be to 
fork(fix) commons-logging.  This version could just directly use 
log4j(or whatever) instead of relying on the classloader to work it 
out.  You might then have to replace all instances of the 
commons-logging jar in the app server.

Mike
On Aug 27, 2004, at 7:27 PM, Oleg Kalnichevski wrote:
Hi Eric
Personally up to now I have not had too much of a hard time using
commons-logging with Websphere 5.0 and 5.1. Maybe I was just lucky
You may want to fork off the HttpClient 2.0 branch and host it on the
SourceForge, for instance. HttpClient 2.0 is stable and will not be
actively developed in the future. So you should not have too much
trouble keeping the forked version in sync with the official one. The
drawback of this approach is that once HttpClient 3.0 is out you may
have to repeat the whole exercise again. So, probably a better solution
would be to develop a simple converter, which would walk through the
source code and replace all the references to commons-logging with 
log4j
or jdk14. Such a converter could be used against any other
commons-logging dependent library or application, so it might be a
worthwhile investment.

We'd happily include this utility into the contrib package
Just a bunch of random thoughts
Oleg

On Sat, 2004-08-28 at 00:39, Eric Bloch wrote:
Hey Folks,
I've experienced a few problems with httpclient not instantiating in a
web application under some containers (websphere 5.1 is the latest, 
but
I've seen problems in tomcat and ATG as well).  This turns out to
*always* be a problem with class-loading and commons-logging.  It's 
hard
to precisely describe the problems, but it always seems like it has
something to do with different class-loaders loading the 
commons-logging
  api or implementation jar.

I'm wondering what the current advice is on common-logging.  See
http://www.qos.ch/logging/thinkAgain.html for details on links to the
numerous problems and problem reports with commons-logging.  I 
imagine I
could be walking into a religious debate here, bu, as far as I can 
tell,
commons-logging is basically broken wrt to its class-loader and the
servlet-container spec for class-loading.  (It always chooses the Java
spec rather than the servlet container spec).

I really only care about httpclient, but unfortunately, it seems I'm
stuck with commons-logging because httpclient uses it.  The only plan 
I
can think of now is to remove commons-logging from httpclient.

1) Is there anyone else interested in a copy of httpclient modified to
use either jdk1.4 logging or log4j logging directly?  Any preferences
(me I prefer log4j mostly because it's what I'm accustomed to).
2) Anyone have any advice on how to maintain a copy of httpclient that
avoided commons-logging?
3) Anyone know any commons-logging folks I can email/talk to?
FWIW, I'm not a class-loader expert.  I've tried to explain the 
problems
to commons-logging folks in a bug I filed (and in other bugs I've 
read),
but I don't see this getting resolved in a timely fashion.

-Eric

A few details btw:
To get things working in ATG, I had to:
- unjar DAS/lib/classes.jar
- remove org/apache/common/*
- jar it back up into classes.jar
I also removed the common_logging.jar file (it looks like there are 
some
additional org.apache.common.logging classes in there too)


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


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


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

Re: HttpClient Reading Partial Response

[Michael Becke]

Hi Manish,
Just to echo Orwin's comments, what you're asking should be handled at 
the application level, instead of the protocol level (HTTP).  It sounds 
like what you want is paging.  My suggestion would be to control the 
location and size of the values returned by passing in additional 
parameters in the request.  For example if you could specify something 
like the following:  http://myhost/path/request?start=100length=100.  
This would get the second 100 records.

Mike
On Aug 24, 2004, at 12:41 AM, Manish Moorjani wrote:
Hi Mike,
Thanks for the quick response.
What I mean by partial response is as follows :
When I try accessing the url directly the application can do do things
1) Returns the response in one go
2) Keep on flushing after some data is fetched(say there are total 100 
records, it displays 100 records first still the other 900 are getting 
fetched)

How do I implement the option 2 using HttpClient, that is can I get 
some part of the response from the URL and display it on screen and 
then make a
request for remaining part so that timeout doesnt take place.

Something like can I set the response lenght fetchech to say 1000 and 
the next time I make a new request I get the response after those 100 
bytes.

The Suggestions given by u are good.
But I dont want to increase the timeout time for request because in 
that case I will have to wait for that much longer for a url which is 
not responding at all !!!

I hope I made it clear.
Regards,
Manish Moorjani
If you are still amazed by something you accomplished yesterday then 
today has been a waste

Hello Manish,
What you're doing here looks good.  It sounds like you're getting a
socket read timeout which is caused by a large delay when reading the
response.  I'm not sure what you mean by read partial responses.  The
only options I can think of are setting the SO_TIMEOUT to a higher
value, or working on the server side to increase its performance.
Mike
On Aug 22, 2004, at 8:27 AM, Manish Moorjani wrote:
Hi,
I am using HttpClient for automatic login into third Party
Applications and then fetching the page and displaying it to the end
user.
The page I am trying to fetch queries the database based on a search
key and fetches more than 2000 records to display on the screen.
I am using the following code to fetch the response
StringBuffer sReply =new StringBuffer();
InputStream rbas = method.getResponseBodyAsStream();
InputStreamReader isr = new InputStreamReader (rbas, UTF8 /* UTF8
*/);
BufferedReader br = new BufferedReader (isr);
while ((temp = (br.readLine())) != null) {
sReply.append(temp+ \r\n);
}
String strReply=sReply.toString();
method.releaseConnection();
br.close();
isr.close();
rbas.close();
}
But as the response is large sometimes the request times out before
the response is obtained.
Is there a way possible to read partial responses and displaying them
on the screen ???
Or the only option is to set the timeout time to max possible ?
One more thing the records are fetched quite fast when I directly
access the url
Regards,
Manish Moorjani
Infosys Technologies Ltd.
Phone: 91-44-24509530/40/50 Extn. 80395
If you are still amazed by something you accomplished yesterday then
today has been a waste
Regards,
Manish Moorjani
Infosys Technologies Ltd.
Phone: 91-44-24509530/40/50 Extn. 80395
If you are still amazed by something you accomplished yesterday then 
today has been a waste

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


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

Re: Status Bar keeps on going

[Michael Becke]

Yes, I'm also a little confused about what you mean here Manish.
Mike
On Aug 24, 2004, at 5:00 AM, Ortwin Glück wrote:

Manish Moorjani wrote:
When I use the HttpClient even after the page is fetched and 
displayed on the browser, I still see the status bar(of browser) 
movng for about 20 seconds.
Manish,
I guess you need to explain the relation between Internet Explorer and 
HttpClient. Because by default there is none.

Ortwin Glück
-
To unsubscribe, e-mail: 
[EMAIL PROTECTED]
For additional commands, e-mail: 
[EMAIL PROTECTED]


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

Re: HttpClient and Java.nio?

[Michael Becke]

Hi Andre,
To my knowledge no-one has done much work with HttpClient and NIO.  
Theoretically speaking I don't know if NIO would have much (if any) of 
an impact though.

Mike
On Aug 24, 2004, at 5:44 PM, Andre-John Mas wrote:
Hi,
Has anyone done any experimentation to see if Java NIO could add 
anything
extra, performance wise, to HttpClient?

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

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

Re: HttpClient Reading Partial Response

[Michael Becke]

Hello Manish,
What you're doing here looks good.  It sounds like you're getting a 
socket read timeout which is caused by a large delay when reading the 
response.  I'm not sure what you mean by read partial responses.  The 
only options I can think of are setting the SO_TIMEOUT to a higher 
value, or working on the server side to increase its performance.

Mike
On Aug 22, 2004, at 8:27 AM, Manish Moorjani wrote:
Hi,
I am using HttpClient for automatic login into third Party 
Applications and then fetching the page and displaying it to the end 
user.

The page I am trying to fetch queries the database based on a search 
key and fetches more than 2000 records to display on the screen.

I am using the following code to fetch the response
StringBuffer sReply =new StringBuffer();
InputStream rbas = method.getResponseBodyAsStream();
InputStreamReader isr = new InputStreamReader (rbas, UTF8 /* UTF8 
*/);
BufferedReader br = new BufferedReader (isr);
while ((temp = (br.readLine())) != null) {
sReply.append(temp+ \r\n);
}
String strReply=sReply.toString();
method.releaseConnection();
br.close();
isr.close();
rbas.close();
}

But as the response is large sometimes the request times out before 
the response is obtained.
Is there a way possible to read partial responses and displaying them 
on the screen ???
Or the only option is to set the timeout time to max possible ?

One more thing the records are fetched quite fast when I directly 
access the url

Regards,
Manish Moorjani
Infosys Technologies Ltd.
Phone: 91-44-24509530/40/50 Extn. 80395
If you are still amazed by something you accomplished yesterday then 
today has been a waste

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


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

Re: Status bar keeps on going

[Michael Becke]

Hi Manish,
It's pretty hard to say from the information provided.  HttpClient does 
not come with a status bar so it depends on how you've implemented it.  
If you post some sample code showing the problem and a wire log 
http://jakarta.apache.org/commons/httpclient/logging.html we should 
be able to help out.

Mike
On Aug 22, 2004, at 9:42 AM, Manish Moorjani wrote:
Hi ,
I am using HttpClient for fetching urls and displaying pages.
the issue I am facing is that even after the entire page is displayed 
the status bar keeps moving for some
time abt 20 seconds, the logs dont show me anything
I tried something in response.flush()
response.flushbuffer()
but still this is happening ?
Does anybody has any idea abt this ?

Regards,
Manish Moorjani
Infosys Technologies Ltd.
Phone: 91-44-24509530/40/50 Extn. 80395
If you are still amazed by something you accomplished yesterday then 
today has been a waste

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


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

Re: Response content length is not known

[Michael Becke]

Hi Joseph,
Please post a full debug + wire log of the transaction  
http://jakarta.apache.org/commons/httpclient/logging.html.  This will  
give us a better idea of what's happening.

Thanks,
Mike
On Aug 17, 2004, at 8:07 AM, joseph mercado wrote:
HI list;
   Im using httpClient-2.0. I trying to post an xml
data, parse xml to assemble the post data to be posted
to several sequence of jsp page. I got all the
response body for the all the page except the last
one. I set logging to debug. On each page i got
warning. What's causing this and why cant i get the
last html page. the log below should print the last
html page.

19:48:46,585 INFO  [STDOUT] ?xml version=1.0
encoding=UTF-8?ereg bId=123456
uId=josephformlastNameMercado/lastNamefirstNameJoseph/ 
firstNamemiddleNameG/middleNamebirthDate11-18-1978/ 
birthDateregistrationTypeindividual/registrationType/ 
formformagreeYES/agree/formformsexM/ 
sexprofessionalType1
ACCOUNTANT amp;
AUDITOR/professionalType1citizenshipFIL/ 
citizenshipbusinessSubStreet2158
-A/businessSubStreetbusunessStreetMindanao
Avenue/busunessStreetbusinessBarangay501/ 
businessBarangaybusinessDistrictSta.
Mesa/businessDistrictbusinessCityMetro
Manila/businessCitybusinessTelephone8122124/ 
businessTelephonecontactLastNamePuno/ 
contactLastNamecontactFirstNameRico/ 
contactFirstNamecontactMiddleInitialJay/ 
contactMiddleInitialcontactPersonTelephone8765432/ 
contactPersonTelephoneactionBIRpage2/action/ 
formformtaxType1IT/taxType1taxType23RF/ 
taxType23actionBIRpage3/action/formformcivilStatusMA/ 
civilStatusspouseLastNameMercado/ 
spouseLastNamespouseFirstNameMa.
Andrelita/spouseFirstNamespouseMiddleNameCajobe/ 
spouseMiddleNamespouseTin213122312/ 
spouseTinspouseEmployerNameMDI/ 
spouseEmployerNamenoOfDependentChildren1/ 
noOfDependentChildrendependentChildLastName1Mercado/ 
dependentChildLastName1dependentChildFirstName1Andre/ 
dependentChildFirstName1dependentChildMiddleName1C/ 
dependentChildMiddleName1dependentChildIncapacitatedFlag1D1/ 
dependentChildIncapacitatedFlag1additionalClaimsHC/ 
additionalClaimsactionBIRpage4/action/ 
formformmultipleEmploymentType1SE/ 
multipleEmploymentType1previousEmployerTIN1123456789/ 
previousEmployerTIN1previousEmployerName1BPI/ 
previousEmployerName1currentEmployerTIN123456789/ 
currentEmployerTINcurrentRDO051/ 
currentRDOcurrentEmployerNameMDi/ 
currentEmployerNamecurrentEmployerAddress6F
Peninsula Court Paseo
Makati/currentEmployerAddresscurrentEmployerZipCode1200/ 
currentEmployerZipCodecurrentEmployerTelephone8122124/ 
currentEmployerTelephoneactionBIRpage5/action/ 
formformrdoCodeName042
- SAN
JUAN/rdoCodeNamesssNumber21321313122/sssNumberactionconfirm/ 
action/formformactionfinished/action/form/ereg
19:48:46,625 WARN  [HttpMethodBase] Response content
length is not known
19:48:46,625 INFO  [STDOUT]
http://203.215.79.212/reg-dir/validateLogin.do
19:48:46,675 INFO  [STDOUT]
http://203.215.79.212/reg-dir/BIRpage1.do
19:48:59,804 WARN  [HttpMethodBase] Response content
length is not known
19:48:59,804 INFO  [STDOUT]
http://203.215.79.212/reg-dir/BIRpage2.do
19:48:59,854 WARN  [HttpMethodBase] Response content
length is not known
19:48:59,854 INFO  [STDOUT]
http://203.215.79.212/reg-dir/BIRpage3.do
19:49:21,925 WARN  [HttpMethodBase] Response content
length is not known
19:49:21,935 INFO  [STDOUT]
http://203.215.79.212/reg-dir/BIRpage4.do
19:49:21,965 WARN  [HttpMethodBase] Response content
length is not known
19:49:21,965 INFO  [STDOUT]
http://203.215.79.212/reg-dir/BIRpage5.do
19:50:14,721 WARN  [HttpMethodBase] Response content
length is not known
19:50:14,721 INFO  [STDOUT]
http://203.215.79.212/reg-dir/confirm.do
19:50:22,112 WARN  [HttpMethodBase] Response content
length is not known
19:50:22,112 INFO  [STDOUT]
http://203.215.79.212/reg-dir/submitApplication.do
19:50:22,132 WARN  [HttpMethodBase] Response content
length is not known



__
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
-
To unsubscribe, e-mail:  
[EMAIL PROTECTED]
For additional commands, e-mail:  
[EMAIL PROTECTED]


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

Re: Response content length is not known

[Michael Becke]

/
 param name=MaxFileSize value=500KB/
 param name=MaxBackupIndex value=1/
 layout class=org.apache.log4j.PatternLayout
   param name=ConversionPattern value=%d %-5p
[%c] %m%n/
 /layout
   /appender
   category name=org.jgroups
 priority value=DEBUG /
 appender-ref ref=CLUSTER/
   /category
   category name=org.jboss.ha
 priority value=DEBUG /
 appender-ref ref=CLUSTER/
   /category
   --
/log4j:configuration

--- Michael Becke [EMAIL PROTECTED] wrote:

Hi Joseph,
Please post a full debug + wire log of the
transaction  

http://jakarta.apache.org/commons/httpclient/logging.html.
This will  
give us a better idea of what's happening.

Thanks,
Mike
On Aug 17, 2004, at 8:07 AM, joseph mercado wrote:

HI list;
  Im using httpClient-2.0. I trying to post an
xml
data, parse xml to assemble the post data to be
posted
to several sequence of jsp page. I got all the
response body for the all the page except the last
one. I set logging to debug. On each page i got
warning. What's causing this and why cant i get
the
last html page. the log below should print the
last
html page.

19:48:46,585 INFO  [STDOUT] ?xml version=1.0
encoding=UTF-8?ereg bId=123456

uId=josephformlastNameMercado/lastNamefirstNameJoseph/
firstNamemiddleNameG/middleNamebirthDate11-18-1978/
birthDateregistrationTypeindividual/registrationType/
formformagreeYES/agree/formformsexM/

sexprofessionalType1
ACCOUNTANT amp;
AUDITOR/professionalType1citizenshipFIL/ 
citizenshipbusinessSubStreet2158
-A/businessSubStreetbusunessStreetMindanao
Avenue/busunessStreetbusinessBarangay501/ 
businessBarangaybusinessDistrictSta.
Mesa/businessDistrictbusinessCityMetro
Manila/businessCitybusinessTelephone8122124/ 
businessTelephonecontactLastNamePuno/ 
contactLastNamecontactFirstNameRico/ 
contactFirstNamecontactMiddleInitialJay/ 


contactMiddleInitialcontactPersonTelephone8765432/
contactPersonTelephoneactionBIRpage2/action/

formformtaxType1IT/taxType1taxType23RF/ 


taxType23actionBIRpage3/action/formformcivilStatusMA/
civilStatusspouseLastNameMercado/ 
spouseLastNamespouseFirstNameMa.


Andrelita/spouseFirstNamespouseMiddleNameCajobe/
spouseMiddleNamespouseTin213122312/ 
spouseTinspouseEmployerNameMDI/ 
spouseEmployerNamenoOfDependentChildren1/ 


noOfDependentChildrendependentChildLastName1Mercado/
dependentChildLastName1dependentChildFirstName1Andre/
dependentChildFirstName1dependentChildMiddleName1C/
dependentChildMiddleName1dependentChildIncapacitatedFlag1D1/
dependentChildIncapacitatedFlag1additionalClaimsHC/
additionalClaimsactionBIRpage4/action/ 
formformmultipleEmploymentType1SE/ 


multipleEmploymentType1previousEmployerTIN1123456789/
previousEmployerTIN1previousEmployerName1BPI/ 


previousEmployerName1currentEmployerTIN123456789/
currentEmployerTINcurrentRDO051/ 
currentRDOcurrentEmployerNameMDi/ 
currentEmployerNamecurrentEmployerAddress6F
Peninsula Court Paseo


Makati/currentEmployerAddresscurrentEmployerZipCode1200/
currentEmployerZipCodecurrentEmployerTelephone8122124/
currentEmployerTelephoneactionBIRpage5/action/

formformrdoCodeName042
- SAN

JUAN/rdoCodeNamesssNumber21321313122/sssNumberactionconfirm/
action/formformactionfinished/action/form/ereg
19:48:46,625 WARN  [HttpMethodBase] Response
content
length is not known
19:48:46,625 INFO  [STDOUT]
http://203.215.79.212/reg-dir/validateLogin.do
19:48:46,675 INFO  [STDOUT]
http://203.215.79.212/reg-dir/BIRpage1.do
19:48:59,804 WARN  [HttpMethodBase] Response
content
length is not known
19:48:59,804 INFO  [STDOUT]
http://203.215.79.212/reg-dir/BIRpage2.do
19:48:59,854 WARN  [HttpMethodBase] Response
content
length is not known
19:48:59,854 INFO  [STDOUT]
http://203.215.79.212/reg-dir/BIRpage3.do
19:49:21,925 WARN  [HttpMethodBase] Response
content
length is not known
19:49:21,935 INFO  [STDOUT]
http://203.215.79.212/reg-dir/BIRpage4.do
19:49:21,965 WARN  [HttpMethodBase] Response
content
length is not known
19:49:21,965 INFO  [STDOUT]
http://203.215.79.212/reg-dir/BIRpage5.do
19:50:14,721 WARN  [HttpMethodBase] Response
content
length is not known
19:50:14,721 INFO  [STDOUT]
http://203.215.79.212/reg-dir/confirm.do
19:50:22,112 WARN  [HttpMethodBase] Response
content
length is not known
19:50:22,112 INFO  [STDOUT]
http://203.215.79.212/reg-dir/submitApplication.do
19:50:22,132 WARN  [HttpMethodBase] Response
content
length is not known


__
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile
phone.
http://mobile.yahoo.com/maildemo


-
To unsubscribe, e-mail:  


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



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



		
__
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo

Re: parameter of setHost method in HostConfiguration of httpClient

[Michael Becke]

Option 1 is the correct one, but you do not need to call 
client.getHttpConnectionManager().releaseConnection() manually as this 
gets done via Method.releaseConnection().

Mike
Kalnichevski, Oleg wrote:
The former (option 1) is the correct one. The latter (option 2)
_should_ work with the simple connection manager but it is guaranteed
to not produce the desired effect with the multi-threaded connection
manager
Oleg
-Original Message- From: Karthikeyani K
[mailto:[EMAIL PROTECTED] Sent: Tuesday, August 10, 2004 18:58
 To: Commons HttpClient Project Subject: RE: parameter of setHost
method in HostConfiguration of httpClient
Kalnichevski, I want to close the client connection once the method
has been executed. Still I am not clear.Here is what I
understand...There are two ways of doing it. Which option is the
proper way of closing a client connection. Is my understanding
correct.
1)public  class myHttpConnectionManager extends
SimpleHttpConnectionManager public myHttpConnectionManager() {}; 
public void releaseConnection(HttpConnection connection) { 
super.releaseConnection(connection); connection.close(); }

} HttpClient client = new HttpClient( myHttpConnectionManager); 
PostMethod method =  new PostMethod(http://test:80/test.html); //
After executing the post method when i try to close the

connection, i get the error message host is null 
method.releaseConnection(); // Close the connection 
client.getHttpConnectionManager().releaseConnection().


or
2)HttpClient client = new HttpClient( myHttpConnectionManager); 
PostMethod method =  new PostMethod(http://test:80/test.html); //
After executing the post method when i try to close the

connection, i get the error message host is null 
method.releaseConnection(); // Close the connection 
client.getHttpConnectionManager().getConnection(method.getHostConfiguration()).close().


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

Thanks, Karthi
Kalnichevski, Oleg [EMAIL PROTECTED] wrote:
Karthi,
Host configuration specified at the HTTP method level is not supposed
to be propagated back to the HTTP client level.
Try this instead
// Close the connection 
client.getHttpConnectionManager().getConnection(method.getHostConfiguration()).close

Better yet, subclass the connection manager and make it always close
connections upon release (if that is what you want). The way you are
trying to get this done seems a little flaky to me.
HttpConnectionManager#getConnection method will produce ANY
connection for the given host config, not the one that has just been
used to execute the request.
Cheers,
Oleg
-Original Message- From: Karthikeyani K
[mailto:[EMAIL PROTECTED] Sent: Tuesday, August 10, 2004 16:57
 To: Commons HttpClient Project Subject: RE: parameter of setHost
method in HostConfiguration of httpClient
Thanks Kalnichevski. But I have specified the host at the method
level : for eg: HttpClient client = new HttpClient(); PostMethod
method = new PostMethod(http://test:80/test.html); // After executing
the post method when i try to close the connection, i get the error
message host is null method.releaseConnection(); // Close the
connection 
client.getHttpConnectionManager().getConnection(client.getHostConfiguration()).close()


There is a method setHost(URI uri) in HostConfiguration. So I was
thinking this should be the URI same as that specified in the
PostMethod.i.e that of the server
Thanks, Karthi
Kalnichevski, Oleg wrote:
Karthi,
HostConfiguration associated with HttpClient instance represents
default host information. These settings are used only when the
target host and port are not explicitly specified on the HttpMethod
level.
HttpClient agent = new HttpClient(); 
agent.getHostConfiguration().setHost(localhost, 8080);

HttpMethod absolute = new GetMethod(www.whatever.com/stuff); //
will target the host specified in the URL
HttpMethod relative = new GetMethod(/stuff); // no host name given
in the URL. Will target the default host, that is 'localhost'
Hope this clarifies things a little
Oleg

-Original Message- From: Karthikeyani K
[mailto:[EMAIL PROTECTED] Sent: Tuesday, August 10, 2004 15:39
 To: [EMAIL PROTECTED] Subject: parameter of
setHost method in HostConfiguration of httpClient
Hi, When we set Host on the HostConfiguration of the httpClient using
setHost method (setHost(host)), does the host correspond to the
server host or the client host.
When I try to close a connection by using 
cleint.getHttpConnectionmanager.getConnection(client.getHostConfiguration()).close,
 I am getting the error stating host is null. So I have to set the
host on the hostConfiguration, so does this host correspond to the
server host or the client host itself.

Please advice.
Thanks, Karthi
- Do you Yahoo!? New and Improved
Yahoo! Mail - 100MB free storage!
***
 The information in this email is 

Re: Error on Oracle App Server Admin Page

[Michael Becke]

Hi Steve,
It looks like you're getting a bad connection.  My guess is that the  
server is closing the connection between requests.  Are you using SSL  
by chance?  Please try setting the connection header to close on your  
requests and see what happens:

Method.setRequestHeader(Connection, close);
Mike
On Aug 10, 2004, at 1:06 PM, Steve Johnson wrote:
Hi All,
I am getting slightly different, but similar results from 2 Oracle App  
Server Admin Pages.

Here are the links, they both use Basic authentication, as confirmed  
by the WIRE debug.
Also the HTTP Request looks identical from HTTPClient and IE when  
viewed in a sniffer.
In both cases the first request is missing the:
Authorization: Basic YWRtaW5pc3RyYXRvcjphZG1pbmlzdHJhdG9y
header line and the response is 401.
The second request includes this line and IE works with 200.
HTTPClient does not get any response headers, but gets these  
exceptions:

http://maximus.mercury.co.il:4003/webcacheadmin? 
SCREEN_ID=CGA.Site.Stats
http://maximus.mercury.co.il:4003/webcacheadmin? 
SCREEN_ID=CGA.Site.StatsACTION=Show ACTION=Show
org.apache.commons.httpclient.HttpRecoverableException:
org.apache.commons.httpclient.HttpRecoverableException: Error in  
parsing the status line from the response:
unable to find line starting with HTTP

http://localhost:/SiteScope/cgi/go.exe/SiteScope? 
page=adhocReportmonitors=2+oracleaccount=administrator
group=oracledetailed=true  
http://sunqa1:4000/webcacheadmin?SCREEN_ID=CGA.Site.StatsACTION=Show
org.apache.commons.httpclient.HttpRecoverableException:  
java.net.SocketException: Software caused connection
abort: recv failed

Both requests look identical to me:
GET /webcacheadmin?SCREEN_ID=CGA.Site.StatsACTION=Show HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,  
application/x-shockwave-flash,
application/vnd.ms-excel, application/vnd.ms-powerpoint,  
application/msword, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Host: sunqa1:4000
Connection: Keep-Alive
Authorization: Basic YWRtaW5pc3RyYXRvcjphZG1pbmlzdHJhdG9y

The only thing that looks different in the sniffer is the client port.
HTTPClient uses the same client port for both requests, without and  
with Authorizaiton:
IE uses different ports on each request.

I didnt find anything in old bugs.
Thanks for you help,
Steve
Steve Johnson
Software Engineer
Mercury Interactive
720 564 - 6532
USA, Canada and the Americas
720 564-6620
Hours: M-F 08:00-17:00 MST (Mountain Standard Time)

 http://www.mercuryinteractive.com http://www.mercuryinteractive.com
Looking for Answers to your SiteScope or SiteSeer questions? 
http://support.mercuryinteractive.com
http://support.mercuryinteractive.com




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

Re: Follow up to Bug 30514

[Michael Becke]

Hi Neil,
My guess is that the lost connections are eventually GCed.  The 
multi-threaded connection manager listens for GCed connections and 
decrements the count of created connections when this occurs.  This 
feature is meant as a fail safe and should not be relied upon as 
garbage collection is by design sporadic and unreliable.

Mike
On Aug 9, 2004, at 7:30 PM, [EMAIL PROTECTED] wrote:
Hi,
This is in reference to a bug I filed where HttpClient seemed to freeze
when under heavy concurrent access.  The bug was closed noting that I
wasn't closing the connection in my test.  This was true, however if I 
set
the connection pool size to be much larger than the number of threads 
the
problem never occurs.  The pool comes close to filling up and then it
cleans itself out.

What I'd like to know is - is there a case when the cleaner thread
realizes it can clean these not-closed connections out?  I can't 
reproduce
this problem in the single-threaded case, and need to know more to be 
able
to reproduce this and verify it has been fixed in our application.

Thanks for your help,
Neil Thier

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

Re: Invoke a httpclient in a EJB

[Michael Becke]

Hi Karthi,
So does the following code snippet perform what Mike have mentioned...
HttpClient client=new HttpClient(); // Which will create a 
SimpleHttpConnectionManager
  // by default. So we 
need not create an explicit
  
//HttpconnectionManager

   // Perform post
  ..
   //Release the connection
 postmethod.releaseConnection();
   // Close the socket connection
client.getHttpConnectionManager().getConnection().close();
Is this the correct way of closing the connection.
That should work just fine.
Mike
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoke a httpclient in a EJB

[Michael Becke]

Hi Karthi,
From the wording it sounds like you are not supposed to run a server 
from an EJB.  HttpClient creates sockets but it does not listen to or 
accept connections, it's a client only.  As someone already mentioned it 
would be pretty useless if you couldn't make network connections from an 
EJB as that would eliminate JDBC as well.

It sounds like the real issue is going to be thread creation and 
connection reuse.  To avoid creating threads you should use neither the 
MultiThreadedHttpConnectionManager nor connection timeouts.  Both of 
these will create threads.  You will also need to ensure that all 
HttpConnections are closed when the EJB exists.  I would suggest 
creating a simple HttpConnectionManager (very similar to 
SimpleHttpConnectionManager) that you can force close the connection with.

Mike
Karthikeyani K wrote:
Thanks everyone.
The EJB restrictions specified at
http://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html state
that Enterprise beans should not listen on, accept connections on, or
mutlicast from a network socket. Why can an enterprise bean not
listen to or accept connections on a socket? Because if an enterprise
bean is listening on a socket, it can't be passivated -- it must
always be available. Enterprise beans can be network socket clients,
and so they can use other network resources (including other
enterprise bean servers) to do their jobs. Just as with a database
connection, don't hang on to open client sockets across method calls;
instead, open them, communicate through the socket, and close it
before returning from the method.
So does it mean that we cannot use a HttpClient to invoke a
postmethod from within a EJB, as httpclient creates sockets.  Please
clarify. Is there any other alternate way.
Thanks,
Karthi
Gareth Davis [EMAIL PROTECTED] wrote: EJB + threads +
httpclient... yes does break the letter of the spec's, but yep it
works and it works just fine.
Who ever wrote the spec that said you couldn't open a socket in an
EJB really wasn't living in the real world.
The only thing to watch is that MultiThreadedConnectionManager does 
start it's own thread for managing the pool, this does work in an EJB
 but it won't be shutdown correctly when the application is stopped,
you may find that you create a thread leak.

Having said this I've only tried this in WebSphere 4 and 5. Version 4
 it wasn't a big deal as the process for the appserver got restarted
 when re-installing the app, but in websphere 5 it caused a leak.
Gareth Davis Logical Practice Systems Limited
[EMAIL PROTECTED] On 4 Aug 2004, at 16:20, Karthikeyani K
wrote:

Hi, We have all requests posted to a servlet which delegates the 
request to a Stateless Session Bean. Does creatring and invoking a
 Httpclient postmethod in a helper class invoked by the Stateless 
Session Bean violate any of the EJB specifications. (EJB spec says
 sockets are not to be created in EJB code etc. ). Please suggest.

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

-
 To unsubscribe, e-mail:
[EMAIL PROTECTED] For additional
commands, e-mail: [EMAIL PROTECTED]
 - Do you Yahoo!? New and Improved
Yahoo! Mail - Send 10MB messages!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: No no-cookie Policy in 2.0.1?

[Michael Becke]

Hi Doug,
The ignore cookies policy was added in 3.0 alpha1.  The release notes  
you quote are from this release.  My guess is that you are looking at  
the 2.0 source code and documentation, which does not include this  
feature.  The 2.0.1 release notes are available at  
http://www.apache.org/dist/jakarta/commons/httpclient/RELEASE-NOTES 
-2.0.txt.

Mike
On Aug 4, 2004, at 11:26 AM, Doug wrote:
The release notes  
(http://www.apache.org/dist/jakarta/commons/httpclient/RELEASE-NOTES)  
say:
-
(4) Cookie management

 * 'Ignore cookies' cookie policy
-
But I'm not finding this capability in the docs or source code.  Am I  
just missing something?

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


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

Re: Invoke a httpclient in a EJB

[Michael Becke]

Hi Karthi,
Unfortunately I don't have much experience with EJBs, but if the spec 
says that you can't open sockets, then it will be pretty hard to use 
HttpClient.  Perhaps someone else on this list has some more experience 
in this matter.

Any EJB + HttpClient users out there?
Mike
On Aug 4, 2004, at 11:20 AM, Karthikeyani K wrote:
Hi,
We have all requests posted to a servlet which delegates the 
request to a Stateless Session Bean. Does creatring and invoking a 
Httpclient postmethod in a helper class invoked by the Stateless 
Session Bean violate any of the EJB specifications. (EJB spec says 
sockets are not to be created in EJB code etc. ). Please suggest.

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

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

Re: Documentation Updates

[Michael Becke]

Hi Adrian,
Could you add these to 2.0 as well?  The site is currently built from  
2.0.

Mike
On Aug 3, 2004, at 12:12 AM, Adrian Sutton wrote:
These updates have now been committed and will go live whenever the  
site is next deployed.

Regards,
Adrian Sutton.
On 02/08/2004, at 9:53 PM, Michael Becke wrote:
Sounds good.
Mike
On Aug 2, 2004, at 3:41 AM, Adrian Sutton wrote:
Some minor documentation updates:
* Remove To be completed from the index pages.  Those pages were  
completed long ago.
* Moved the call to releaseConnection into a finally block in the  
tutorial (that code is getting copied into a lot of projects so we  
should probably get it right).
* Added a note that users should ensure that log4j is configured to  
avoid performance problems.  (Bug 29973)

Patch is inline below, if I don't hear any complaints I'll commit it  
later on tonight or tomorrow.

Regards,
Adrian Sutton.
Index: logging.xml
===
RCS file: /home/cvs/jakarta-commons/httpclient/xdocs/logging.xml,v
retrieving revision 1.13
diff -u -r1.13 logging.xml
--- logging.xml	5 Jul 2004 20:47:53 -	1.13
+++ logging.xml	2 Aug 2004 07:35:07 -
@@ -142,6 +142,11 @@
 log4j.logger.org.apache.commons.httpclient=DEBUGbr /
 /blockquote
  /p
+ pNote that the default configuration for Log4J is  
very
+ inefficient as it causes all the logging information  
to be
+ generated but not actually sent anywhere.  The Log4J  
manual is the
+ best reference for how to configure Log4J.  It is  
available at a
+  
href=http://logging.apache.org/log4j/docs/manual.html;http:// 
logging.apache.org/log4j/docs/manual.html/a
   /subsection
   /section
/body
Index: tutorial.xml
===
RCS file: /home/cvs/jakarta-commons/httpclient/xdocs/tutorial.xml,v
retrieving revision 1.5
diff -u -r1.5 tutorial.xml
--- tutorial.xml	23 Feb 2004 23:05:43 -	1.5
+++ tutorial.xml	2 Aug 2004 07:35:07 -
@@ -207,39 +207,44 @@

 // Create a method instance.
 HttpMethod method = new GetMethod(url);
-
-// Execute the method.
-int statusCode = -1;
-// We will retry up to 3 times.
-for (int attempt = 0; statusCode == -1  attempt  3;  
attempt++) {
-  try {
-// execute the method.
-statusCode = client.executeMethod(method);
-  } catch (HttpRecoverableException e) {
-System.err.println(
-  A recoverable exception occurred, retrying. +
-  e.getMessage());
-  } catch (IOException e) {
-System.err.println(Failed to download file.);
-e.printStackTrace();
-System.exit(-1);
+
+try {
+  // Execute the method.
+  int statusCode = -1;
+  byte[] responseBody = null;
+  // We will retry up to 3 times.
+  for (int attempt = 0; statusCode == -1  attempt   
3; attempt++) {
+try {
+  // execute the method.
+  statusCode = client.executeMethod(method);
+} catch (HttpRecoverableException e) {
+  System.err.println(
+A recoverable exception occurred, retrying. +
+e.getMessage());
+} catch (IOException e) {
+  System.err.println(Failed to download file.);
+  e.printStackTrace();
+  System.exit(-1);
+}
+  }
+  // Check that we didn't run out of retries.
+  if (statusCode == -1) {
+System.err.println(Failed to recover from  
exception.);
+System.exit(-2);
   }
-}
-// Check that we didn't run out of retries.
-if (statusCode == -1) {
-  System.err.println(Failed to recover from  
exception.);
-  System.exit(-2);
-}

-// Read the response body.
-byte[] responseBody = method.getResponseBody();
+  // Read the response body.
+  responseBody = method.getResponseBody();
-// Release the connection.
-method.releaseConnection();
+} finally {
+  // Release the connection.
+  method.releaseConnection();
+}
 // Deal with the response.
 // Use caution: ensure correct character encoding and  
is not binary data
 System.err.println(new String(responseBody));
+
   }
 }
   ]]/source
Index: userguide.xml
===
RCS file: /home/cvs/jakarta-commons/httpclient/xdocs/userguide.xml,v
retrieving revision 1.2
diff -u

Re: Documentation Updates

[Michael Becke]

Sounds good.
Mike
On Aug 2, 2004, at 3:41 AM, Adrian Sutton wrote:
Some minor documentation updates:
* Remove To be completed from the index pages.  Those pages were  
completed long ago.
* Moved the call to releaseConnection into a finally block in the  
tutorial (that code is getting copied into a lot of projects so we  
should probably get it right).
* Added a note that users should ensure that log4j is configured to  
avoid performance problems.  (Bug 29973)

Patch is inline below, if I don't hear any complaints I'll commit it  
later on tonight or tomorrow.

Regards,
Adrian Sutton.
Index: logging.xml
===
RCS file: /home/cvs/jakarta-commons/httpclient/xdocs/logging.xml,v
retrieving revision 1.13
diff -u -r1.13 logging.xml
--- logging.xml	5 Jul 2004 20:47:53 -	1.13
+++ logging.xml	2 Aug 2004 07:35:07 -
@@ -142,6 +142,11 @@
 log4j.logger.org.apache.commons.httpclient=DEBUGbr /
 /blockquote
  /p
+ pNote that the default configuration for Log4J is very
+ inefficient as it causes all the logging information to  
be
+ generated but not actually sent anywhere.  The Log4J  
manual is the
+ best reference for how to configure Log4J.  It is  
available at a
+  
href=http://logging.apache.org/log4j/docs/manual.html;http:// 
logging.apache.org/log4j/docs/manual.html/a
   /subsection
   /section
/body
Index: tutorial.xml
===
RCS file: /home/cvs/jakarta-commons/httpclient/xdocs/tutorial.xml,v
retrieving revision 1.5
diff -u -r1.5 tutorial.xml
--- tutorial.xml	23 Feb 2004 23:05:43 -	1.5
+++ tutorial.xml	2 Aug 2004 07:35:07 -
@@ -207,39 +207,44 @@

 // Create a method instance.
 HttpMethod method = new GetMethod(url);
-
-// Execute the method.
-int statusCode = -1;
-// We will retry up to 3 times.
-for (int attempt = 0; statusCode == -1  attempt  3;  
attempt++) {
-  try {
-// execute the method.
-statusCode = client.executeMethod(method);
-  } catch (HttpRecoverableException e) {
-System.err.println(
-  A recoverable exception occurred, retrying. +
-  e.getMessage());
-  } catch (IOException e) {
-System.err.println(Failed to download file.);
-e.printStackTrace();
-System.exit(-1);
+
+try {
+  // Execute the method.
+  int statusCode = -1;
+  byte[] responseBody = null;
+  // We will retry up to 3 times.
+  for (int attempt = 0; statusCode == -1  attempt  3;  
attempt++) {
+try {
+  // execute the method.
+  statusCode = client.executeMethod(method);
+} catch (HttpRecoverableException e) {
+  System.err.println(
+A recoverable exception occurred, retrying. +
+e.getMessage());
+} catch (IOException e) {
+  System.err.println(Failed to download file.);
+  e.printStackTrace();
+  System.exit(-1);
+}
+  }
+  // Check that we didn't run out of retries.
+  if (statusCode == -1) {
+System.err.println(Failed to recover from  
exception.);
+System.exit(-2);
   }
-}
-// Check that we didn't run out of retries.
-if (statusCode == -1) {
-  System.err.println(Failed to recover from exception.);
-  System.exit(-2);
-}

-// Read the response body.
-byte[] responseBody = method.getResponseBody();
+  // Read the response body.
+  responseBody = method.getResponseBody();
-// Release the connection.
-method.releaseConnection();
+} finally {
+  // Release the connection.
+  method.releaseConnection();
+}
 // Deal with the response.
 // Use caution: ensure correct character encoding and is  
not binary data
 System.err.println(new String(responseBody));
+
   }
 }
   ]]/source
Index: userguide.xml
===
RCS file: /home/cvs/jakarta-commons/httpclient/xdocs/userguide.xml,v
retrieving revision 1.2
diff -u -r1.2 userguide.xml
--- userguide.xml	21 Aug 2003 16:08:54 -	1.2
+++ userguide.xml	2 Aug 2004 07:35:07 -
@@ -30,13 +30,13 @@
 /tr
 tr
   tda href=charencodings.htmlCharacter  
Encodings/a/td
-  tdTo be completed.  Guidelines for correctly detecting the
+  tdGuidelines 

Re: Solution to copy files from one server to another..please

[Michael Becke]

Hi Ganesh,
Thank you for your interest in HttpClient.  Your question, though 
perhaps applicable, is a little too general to elicit much response.  I 
suggest defining the problem more carefully, and then posting specific 
questions about using HttpClient.

Mike
On Aug 2, 2004, at 11:00 AM, ganesh gadi wrote:
Hi list!
This is My requirement:
we are going to use commons-httpclient2.0.1  to copy
files from one server to the other ex: telephone based
trascripting server to Tomcat server
both sides it is demon running ,one transmit the other
listens and receves the files.
OS:win2000 server
Tomcat:5.0.19
httpclient2.0.1
Could anybody give the solution for the above problem
in detail?
it is standalone app with thread running.
i'm new to this commons-httpclient.
Your suggesions are always considered thankfully.
Advance thanks
Ganesh


__
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail
-
To unsubscribe, e-mail: 
[EMAIL PROTECTED]
For additional commands, e-mail: 
[EMAIL PROTECTED]


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

Release time

[Michael Becke]

I'm currently getting 2.0.1 ready for final release.  Expect something 
in the next hour or two.

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

[ANNOUNCE] Release of Commons HttpClient 2.0.1

[Michael Becke]

We are pleased to announce the HttpClient 2.0.1 release.  This version  
contains a few minor bug fixes and enhancements. Please see the release  
notes  
http://www.apache.org/dist/jakarta/commons/httpclient/RELEASE-NOTES 
-2.0.txt for a list of changes made since the 2.0 release.

Please visit the HttpClient Web site  
http://jakarta.apache.org/commons/httpclient/ for more information.

Thank you,
Commons HttpClient Development Team
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: change cookie value

[Michael Becke]

Hi Mathias,
The best way is to just create a new instance of Cookie, copying the 
values you want to keep, and add it to the HttpState.

Mike
On Jul 30, 2004, at 3:09 AM, Mathias Cianci wrote:
Hello everybody,
Is it possible with httpclient to change the value of a specific 
variable sent in a cookie by a server.

For example, when the server send the cookie var1=5*var2=7*var3=4, I 
want to save the cookie var1=5*var2=174*var3=4

Thank you for advance,
Mathias
An happy httpclient-user ;-)

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

Re: Realm for NTLM Authentication

[Michael Becke]

Hi Karthi,
Using null for the NTLM realm is the way to go.  This is covered in a 
little more detail at 
http://jakarta.apache.org/commons/httpclient/authentication.html.

Mike
Karthikeyani K wrote:
Mike, thanks for the answer for my previous question. 
 
I have one more clarification regarding specifying the realm when setting credentials. 
Is it okay to specify null value for realm when setting credentials for NTLM authentication. Does specifying null value, cause any security violation.
 
 
Thanks,
Karthi


-
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: change cookie value

[Michael Becke]

Sweet!  Glad you were able to get it working.
Mike
Mathias Cianci wrote:
Ok!
It works very fine ;-)
   Calendar cal = Calendar.getInstance(TimeZone.getDefault());
   cal.set((Calendar.YEAR),cal.get(Calendar.YEAR)+1);
   java.util.Date d = cal.getTime();HttpClient 
client = new HttpClient();
   HttpState hs = client.getState();
   hs.addCookie(new Cookie(search.msn.fr, smc_classic, 
df=0af=0rc=50nw=0sc=rs=1, /, d, false));
   hs.addCookie(new Cookie(search.msn.fr, smc_g, 
v=1pvs=classicssp=1df=1, /, d, false));
   client.setState(hs);
 

Mathias Cianci a écrit :
Thank you Mike.
But after a long reflexion, I've found that I've not taken the good 
part of the problem.

In fact, what I want to do is to send a Cookie in the headers of my 
first requested page, no matter the cooklies sets by the server.

How to do that ?
Mathias
PS: my english is not really good, don't hesitate to tell me if I'm 
not really comprehensive.

Michael Becke a écrit :
Hi Mathias,
The best way is to just create a new instance of Cookie, copying the 
values you want to keep, and add it to the HttpState.

Mike
On Jul 30, 2004, at 3:09 AM, Mathias Cianci wrote:
Hello everybody,
Is it possible with httpclient to change the value of a specific 
variable sent in a cookie by a server.

For example, when the server send the cookie var1=5*var2=7*var3=4, 
I want to save the cookie var1=5*var2=174*var3=4

Thank you for advance,
Mathias
An happy httpclient-user ;-)


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




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

Re: HttpClient 2.0: Null pointer exception

[Michael Becke]

Hello Francois,
This a pretty strange location for a NPE.  Are you using a stock  
version of HttpClient or have there been any changes made to  
MultiThreadedHttpConnectionManager or HttpConnection?  Also please post  
a wire/debug log  
http://jakarta.apache.org/commons/httpclient/logging.html of a  
session where this problem occurs.

Thanks,
Mike
On Jul 28, 2004, at 1:24 PM, COURTAULT Francois wrote:
Hello,
We have a multi threaded Java program which send HTTP POST to a  
server. Sometimes we got this stack trace:

java.lang.NullPointerException
GCSM1Container  at
org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java: 
109)
GCSM1Container  at
org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:135)
GCSM1Container  at
org.apache.commons.httpclient.HttpParser.parseHeaders(HttpParser.java: 
172)
GCSM1Container  at
org.apache.commons.httpclient.HttpMethodBase.readResponseHeaders(HttpMe 
thodBase.java:2152)
GCSM1Container  at
org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBas 
e.java:1951)
GCSM1Container  at
org.apache.commons.httpclient.HttpMethodBase.processRequest(HttpMethodB 
ase.java:2659)
GCSM1Container  at
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.jav 
a:1093)
GCSM1Container  at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java: 
675)
GCSM1Container  at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java: 
529)

Any idea or fix.
Best Regards.
PS: All the thread has an access to a singleton class which performs  
HTTP POST requests with the following logic:

Singleton initialization:
 MultiThreadedHttpConnectionManager = new  
MultiThreadedHttpConnectionManager();
 HTTPClient httpClient = new HttpClient(httpConnectionManager);

Method sending the POST logic:
try {
PostMethod postMethod = new PostMethod();
httpClient.executeMethod(postMethod);
response = postMethod.getResponseBodyAsString();
} catch()
  finally {
postMethod.releaseConnection();
  }
-
To unsubscribe, e-mail:  
[EMAIL PROTECTED]
For additional commands, e-mail:  
[EMAIL PROTECTED]


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

Re: Username and password encoding

[Michael Becke]

Hello Karthi,
There is no need to encode the username and password.  It gets handled 
as part of the NTLM authentication process.

Mike
On Jul 29, 2004, at 2:40 PM, Karthikeyani K wrote:
Hi,
We are using NTCredentials class from httpClient 
(commons-httpclient-2.0.jar) for NTLM Authentication. Just wanted to 
know whether the username and password passed to the constructor of 
NTCredentials be encoded by using Base64 encoding. or should it be 
passed as a normal username and password without encoding.


Thanks,
Karthi


-
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!

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

Re: Test 2.0.1 release

[Michael Becke]

Well, as people have probably noticed, we don't have a 2.0.1 release 
yet.  I should have some more time at the end of the weekend, and will 
keep you posted.

Thanks,
Mike
On Jul 26, 2004, at 10:27 PM, Michael Becke wrote:
I think we're almost ready for a 2.0.1 release.  CVS has been tagged 
as HTTPCLIENT_2_0_1 and I've uploaded a sample release to my home dir 
at http://www.apache.org/~mbecke/httpclient-2.0.1/.  Please have a 
look and let me know if there is anything missing or incorrect.  If 
all goes well I will post an official release on Wednesday night.

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


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

Re: running with a policy file and system properties

[Michael Becke]

Hi Eric,
Where specifically are you seeing the System.getProperties() calls?  
I'm looking at the latest code in the 2.0 branch (soon to become 2.0.1) 
and everything looks good to me.

Mike
On Jul 26, 2004, at 6:35 PM, Eric Bloch wrote:
I'm walking down the task of making a product that uses httpclient run 
underneath a server with a java policy file.

I know httpclient makes threads and sockets and I believe I have these 
under control (will be allowed or disabled), but I've seen some code 
in the 2.0 code base that does

System.getProperties().getProperty(foo).
Why would you do that instead of System.getProperty(foo) (which 
requires only read access to the property rather than full read/write 
access to all properties) ?

In general, in a server with a policy file, you shouldn't ever depend 
on reading a property (because you might get a SecurityException).  I 
need to either (1) catch the SecurityException or (2) use a simpler 
version of the code that can be enabled without giving access to all 
system properties.

-Eric

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


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

Test 2.0.1 release

[Michael Becke]

I think we're almost ready for a 2.0.1 release.  CVS has been tagged as 
HTTPCLIENT_2_0_1 and I've uploaded a sample release to my home dir at 
http://www.apache.org/~mbecke/httpclient-2.0.1/.  Please have a look 
and let me know if there is anything missing or incorrect.  If all goes 
well I will post an official release on Wednesday night.

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

Re: RV: Please Help !

[Michael Becke]

Hi Arturo,
It seems like you are ending up with partially closed connection.  This  
could be caused by a number of things:

1) the large wait between method executions
2) an older version of JSSE.  JSSE in pre 1.4 JVMs has been known to be  
pretty flaky.
3) the server or proxy server is under high load and simply drops the  
connection.

I would suggest trying one or both of the following:
1) Disable connection reuse by setting the connection: close header  
and/or using HTTP 1.0:

Method.setRequestHeader(Connection, close);
  or
Method.setHttp11(false);
2) Catching the recoverable exception and executing the method again.
Mike
On Jul 23, 2004, at 8:04 AM, Michael Becke wrote:
Please find the message below.
Mike
Begin forwarded message:
 -Mensaje original-
De:     Esquivel Sanchez, Arturo 
Enviado el: Miércoles, 21 de Julio de 2004 06:14 p.m.
Para:   '[EMAIL PROTECTED]'
Asunto: Please Help !

thanks Mike,
I´M USIGN A PROXY, WEBLOGIC SERVER 6.1, RUNNING THE PROCESS FROM UNIX  
AND THIS IS AN EXAMPLE OF MY CODE:
(NOTE: this code runs every 1 minute from a threed.sleep)


url=http://www.whatever.com;;
HttpClient client = new HttpClient();
 client.getState().setProxyCredentials(null, null, new  
UsernamePasswordCredentials(System.getProperty(http.proxyUserName),  
System.getProperty(http.proxyPassword)));

  
client.getHostConfiguration().setProxy(System.getProperty(http.proxyH 
ost),Integer.parseInt(System.getProperty(http.proxyPort,80)));

 GetMethod method1 = new GetMethod(url);
 try{
    statusCode = client.executeMethod(method1);
     System.out.println(Return Code=  + statusCode);
 }catch (HttpRecoverableException e) {
    System.out.println(An recoverable exception  
occurred,retrying.  + e.getMessage());
 e.printStackTrace();
 }finally{
    System.out.println(Releasing Connection method 1. );
    method1.releaseConnection();
 }


THIS IS WHAT THE LOGGING IS DISPLAYING:
(NOTE: i don´t always get this error, most of the time the code works  
fine, but when i get the error and since is a runnable process, i  
need to stop the process by killing its id process, stop the weblogic  
server, wait like 30 minutes, and then try again)



004/07/21 10:10:51:415 CDT [DEBUG] HttpClient - -Java version:  
1.3.1.10
2004/07/21 10:10:51:416 CDT [DEBUG] HttpClient - -Java vendor:  
Hewlett-Packard C
o.
2004/07/21 10:10:51:417 CDT [DEBUG] HttpClient - -Java class path:  
/opt/bea/webl
ogic/v61:/opt/bea/weblogic/v61/lib/weblogic_sp.jar:/opt/bea/weblogic/ 
v61/lib/web
logic.jar:/opt/bea:/opt/bea/weblogic/v61/lib/drivers/jconnect5_5/ 
jconn2.jar:/opt
/bea/weblogic/v61/lib/db2drivers/db2java.zip:/opt/bea/weblogic/v61/ 
lib/db2driver
s/runtime.zip:/opt/bea/weblogic/v61/config/wldominfra01/fml/classes:/ 
opt/bea/web
logic/v61/config/wldominfra01/utilerias/C617_infra.jar:/opt/bea/ 
weblogic/v61/con
fig/wldominfra01/utilerias/jregex1.2_01.jar:/opt/bea/weblogic/v61/ 
config/wldomin
fra01/utilerias/CAME.jar:/opt/bea/weblogic/v61/lib/encripcion/ 
US_export_policy.j
ar:/opt/bea/weblogic/v61/lib/encripcion/local_policy.jar:/opt/bea/ 
weblogic/v61/l
ib/encripcion/jce1_2_2.jar:/opt/bea/weblogic/v61/lib/encripcion/ 
sunjce_provider.
jar:/opt/bea/weblogic/v61/lib/tse/activation.jar:/opt/bea/weblogic/ 
v61/lib/tse/c
astor-0.9.3.9-xml.jar:/opt/bea/weblogic/v61/lib/tse/commons- 
logging.jar:/opt/bea
/weblogic/v61/lib/tse/dom.jar:/opt/bea/weblogic/v61/lib/tse/ 
dom4j.jar:/opt/bea/w
eblogic/v61/lib/tse/fscontext.jar:/opt/bea/weblogic/v61/lib/tse/ 
jaas.jar:/opt/be
a/weblogic/v61/lib/tse/jaxm-api.jar:/opt/bea/weblogic/v61/lib/tse/ 
jaxm-runtime.j
ar:/opt/bea/weblogic/v61/lib/tse/jaxp-api.jar:/opt/bea/weblogic/v61/ 
lib/tse/jaxr
-api.jar:/opt/bea/weblogic/v61/lib/tse/jaxr-apidoc.jar:/opt/bea/ 
weblogic/v61/lib
/tse/jaxr-ri.jar:/opt/bea/weblogic/v61/lib/tse/jaxrpc-api.jar:/opt/ 
bea/weblogic/
v61/lib/tse/jaxrpc-ri.jar:/opt/bea/weblogic/v61/lib/tse/jcert.jar:/ 
opt/bea/weblo
gic/v61/lib/tse/jnet.jar:/opt/bea/weblogic/v61/lib/tse/jsse.jar:/opt/ 
bea/weblogi
c/v61/lib/tse/mail.jar:/opt/bea/weblogic/v61/lib/tse/ 
providerutil.jar:/opt/bea/w
eblogic/v61/lib/tse/regexp.jar:/opt/bea/weblogic/v61/lib/tse/saaj- 
api.jar:/opt/b
ea/weblogic/v61/lib/tse/saaj-ri.jar:/opt/bea/weblogic/v61/lib/tse/ 
sax.jar:/opt/b
ea/weblogic/v61/lib/tse/soap.jar:/opt/bea/weblogic/v61/lib/tse/ 
xalan.jar:/opt/be
a/weblogic/v61/lib/tse/xercesImpl.jar:/opt/bea/weblogic/v61/lib/tse/ 
xsltc.jar:/o
pt/bea/weblogic/v61/lib/tse/TSE.jar:/opt/bea/weblogic/v61/config/ 
wldominfra01/se
rverclasses/CORREODEV.jar:/opt/bea/weblogic/v61/config/wldominfra01/ 
serverclasse
s/C995_055_srv.jar
2004/07/21 10:10:51:428 CDT [DEBUG] HttpClient - -Operating system  
name: HP-UX
2004/07/21 10:10:51:430 CDT [DEBUG] HttpClient - -Operating system  
architecture:
 PA_RISC2.0
2004/07/21 10:10:51:431 CDT [DEBUG] HttpClient - -Operating system  
version: B.11
.00
2004/07/21 10:10:51:432 CDT [DEBUG] HttpClient - -SUN 1.2: SUN (DSA  
key/paramete
r generation

Fwd: RV: Please Help !

[Michael Becke]

/21 10:10:51:768 CDT [DEBUG] HttpMethodBase - -Adding Host  
request header
2004/07/21 10:10:52:242 CDT [DEBUG] HttpMethodBase - -Authorization  
required
2004/07/21 10:10:52:271 CDT [DEBUG] HttpAuthenticator -  
-Authenticating with the
 'Enter Username and Password ' authentication realm at 10.97.106.2
2004/07/21 10:10:52:278 CDT [DEBUG] HttpMethodBase -  
-HttpMethodBase.execute():
Server demanded authentication credentials, will try again.
2004/07/21 10:10:52:282 CDT [DEBUG] HttpMethodBase - -Resorting to  
protocol vers
ion default close connection policy
2004/07/21 10:10:52:282 CDT [DEBUG] HttpMethodBase - -Should NOT close  
connectio
n, using HTTP/1.1.
2004/07/21 10:10:52:282 CDT [DEBUG] HttpMethodBase - -Execute loop try  
2
2004/07/21 10:10:52:283 CDT [DEBUG] HttpMethodBase - -Request to add  
Host header
 ignored: header already added
2004/07/21 10:10:52:285 CDT [DEBUG] HttpMethodBase - -Closing the  
connection.
2004/07/21 10:10:52:286 CDT [INFO] HttpMethodBase - -Recoverable  
exception caugh
t when processing request
2004/07/21 10:10:52:292 CDT [WARN] HttpMethodBase - -Recoverable  
exception caugh
t but MethodRetryHandler.retryMethod() returned false, rethrowing  
exception
An recoverable exception occurred,retrying.   
org.apache.commons.httpclient.HttpR
ecoverableException: Error in parsing the status  line from the  
response: unable
 to find line starting with HTTP
org.apache.commons.httpclient.HttpRecoverableException:  
org.apache.commons.httpc
lient.HttpRecoverableException: Error in parsing the status  line from  
the respo
nse: unable to find line starting with HTTP
    at  
org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodB
ase.java:1965)
    at  
org.apache.commons.httpclient.HttpMethodBase.processRequest(HttpMetho
dBase.java:2659)
    at  
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.j
ava:1093)
    at  
org.apache.commons.httpclient.ConnectMethod.execute(ConnectMethod.jav
a:201)
    at  
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.jav
a:675)
    at  
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.jav
a:529)
    at  
Banamex.C734_000.AeromexicoValida.Proc_Saldo(AeromexicoValida.java:35
7)
    at  
Banamex.C734_000.AeromexicoValida.ValidaServicio(AeromexicoValida.jav
a:134)
    at  
Banamex.C734_000.AeromexicoValida.run(AeromexicoValida.java:68)
    at java.lang.Thread.run(Unknown Source)
Releasing Connection method 1.



hope this help to understand the problem
thanks again
Best Regards
Arturo

Content-Type: text/plain; charset=ISO-8859-1; format=flowed
From: Michael Becke [EMAIL PROTECTED]
Subject: Please Help !
Date: Mon, 19 Jul 2004 21:45:25 -0400
Hello Arturo,
This problem could be caused by a number of things.  Please post a wire
log http://jakarta.apache.org/commons/httpclient/logging.html and
some sample code and we should be able to get to the bottom of the
problem.
Mike
On Jul 19, 2004, at 2:31 PM, Esquivel Sanchez, Arturo wrote:

 Hi,

 I'm getting the error: Error in parsing the status line from the
 response:
 unable to find line starting with HTTP.
 and i´m pretty sure that its related to the consideration documented  
by
 Daniel C. Amadei :

 JSSE prior to Java 1.4 incorrectly reports socket timeout.
 Prior to Java 1.4, in Sun's JSSE implementation, a read operation  
that
 has
 timed out incorrect reports end of stream condition instead of  
throwing
 java.io.InterruptedIOException as expected. HttpClient responds to  
this
 exception by assuming that the connection was dropped and throws a
 recoverable HTTP exception: Error in parsing the status line from the
 response: unable to find line starting with HTTP. It should instead
 report
 java.io.InterruptedIOException: Read timed out. If you see the
 unable to
 find line... message when working with an older version of JDK and
 JSSE, it
 can be caused by the timeout waiting for data and not by a problem
 with the
 connection.
 Work-around: One possible solution is to increase the timeout value  
as
 the
 server is taking too long to start sending the response.  
Alternatively
  you
 may choose to upgrade to Java 1.4 or above which does not exhibit  
this
 problem

 Unfortunely in my company´s tech unit is not going to be easy neither
 quick
 to upgrade to the Java version 1.4.
 And I already tried to increase the client setTimeOut method and  
didn´t
 work

 So is there a way you can help to modified the necesary components in
 order
 to fix the problem from the HttpClient side.
 Or give me some hints on how to fix it and generate a new
 commons-httpclient-2.0.jar that includes the fix.
 Or if there is already a version of the HttpClient v2.0 that fix this
 problem

 The version that i´m using is the 2.0.

 I really really appreciate your help

 Best Regards
 Arturo



-
To unsubscribe, e-mail:  
[EMAIL PROTECTED

[VOTE][RESULT] 2.0.1 release

[Michael Becke]

With 3 +1 votes we'll have a 2.0.1 release shortly.
I should be able to work on the release this weekend.  Please let me  
know if anyone has some time to assist.

Mike
Vote summary:
+1 Michael Becke - mbecke at apache
+1 Oleg Kalnichevski - olegk at apache
+1 Adrian Sutton - adrian at apache
http://nagoya.apache.org/eyebrowse/BrowseList?listName=commons- 
[EMAIL PROTECTED]by=threadfrom=825031

On Jul 18, 2004, at 10:21 PM, Michael Becke wrote:
Pending the patch to bug #29897, I propose that we mark the latest  
code in CVS HTTPCLIENT_2_0 as 2.0.1 and proceed with a release.   
Please vote as follows:

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

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


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

Re: [VOTE] 2.0.1 release

[Michael Becke]

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=29897
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=30175
Both problems are relatively minor. If there are no loud objections I 
commit the patches around 20:00 GMT

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

http://marc.theaimsgroup.com/?t=10838575947r=1w=2
I haven't taken a close look at it, but contrib sounds like the right 
place to me.

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

Re: Please Help !

[Michael Becke]

Hello Arturo,
This problem could be caused by a number of things.  Please post a wire 
log http://jakarta.apache.org/commons/httpclient/logging.html and 
some sample code and we should be able to get to the bottom of the 
problem.

Mike
On Jul 19, 2004, at 2:31 PM, Esquivel Sanchez, Arturo wrote:
Hi,
I'm getting the error: Error in parsing the status line from the 
response:
unable to find line starting with HTTP.
and i´m pretty sure that its related to the consideration documented by
Daniel C. Amadei :

JSSE prior to Java 1.4 incorrectly reports socket timeout.
Prior to Java 1.4, in Sun's JSSE implementation, a read operation that 
has
timed out incorrect reports end of stream condition instead of throwing
java.io.InterruptedIOException as expected. HttpClient responds to this
exception by assuming that the connection was dropped and throws a
recoverable HTTP exception: Error in parsing the status line from the
response: unable to find line starting with HTTP. It should instead 
report
java.io.InterruptedIOException: Read timed out. If you see the 
unable to
find line... message when working with an older version of JDK and 
JSSE, it
can be caused by the timeout waiting for data and not by a problem 
with the
connection.
Work-around: One possible solution is to increase the timeout value as 
the
server is taking too long to start sending the response. Alternatively 
you
may choose to upgrade to Java 1.4 or above which does not exhibit this
problem

Unfortunely in my company´s tech unit is not going to be easy neither 
quick
to upgrade to the Java version 1.4.
And I already tried to increase the client setTimeOut method and didn´t
work

So is there a way you can help to modified the necesary components in 
order
to fix the problem from the HttpClient side.
Or give me some hints on how to fix it and generate a new
commons-httpclient-2.0.jar that includes the fix.
Or if there is already a version of the HttpClient v2.0 that fix this
problem

The version that i´m using is the 2.0.
I really really appreciate your help
Best Regards
Arturo

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

[VOTE] 2.0.1 release

[Michael Becke]

Pending the patch to bug #29897, I propose that we mark the latest code  
in CVS HTTPCLIENT_2_0 as 2.0.1 and proceed with a release.  Please vote  
as follows:

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

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

Re: [VOTE] 2.0.1 release

[Michael Becke]

+1 :)
On Jul 18, 2004, at 10:21 PM, Michael Becke wrote:
Pending the patch to bug #29897, I propose that we mark the latest  
code in CVS HTTPCLIENT_2_0 as 2.0.1 and proceed with a release.   
Please vote as follows:

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

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


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

Re: Getting exception: Unbuffered entity enclosing request can not be repeated

[Michael Becke]

Yes, HttpClient will buffer the content if you use CONTENT_LENGTH_AUTO.
Mike
On Jul 13, 2004, at 3:20 AM, Ingo Brunberg wrote:
The problem is that you are using chunked transfer encoding. This
prevents Httpclient to automatically buffer the content in memory and
the InputStream can only be read once.
The workaround is simply to provide the exact content-length.
Ingo
Hi,
I wonder if anyone could offer a suggestion for getting around an
exception I'm seeing.
I am writing a load test client that sends requests to a webdav 
server.
I have a putMethod which does the following:

PutMethod method = new 
PutMethod(URIUtil.encodePathQuery(path));
generateIfHeader(method);
if (getGetContentType() != null  
!getGetContentType().equals())
method.setRequestHeader(Content-Type, 
getGetContentType());

method.setRequestContentLength(PutMethod.CONTENT_LENGTH_CHUNKED);
method.setRequestBody(bis);
int statusCode = client.executeMethod(method);
bis is a BufferedInputStream.
This method works fine when sending requests using Basic
authentication. However, I want to use Digest authentication (I have
setAuthenticationPreemptive set to false). When sending the request
using Digest, I get the exception:
org.apache.commons.httpclient.HttpException: Unbuffered entity
enclosing request can not be repeated.
In looking at the code, it appears that
EntityEnclosingMethod.writeRequestBody does not cache the request 
body.
So, when the request is resent (with the digest auth header), the
contentCache is null, thus the exception.

Does anyone know of a way around this?
Thanks,
Jennifer

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


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

Re: Getting exception: Unbuffered entity enclosing request can not be repeated

[Michael Becke]

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

Mike
On Jul 13, 2004, at 6:42 PM, Jennifer Ward wrote:
Yes, setting CONTENT_LENGTH_AUTO does buffer the content. However, in 
doing this I realized it's not really the best solution since the 
content will get sent twice (although, it gets ignored the first 
time). So, it's not efficient.

In retrospect what I really want to do is establish the connection 
once (perhaps by sending an OPTIONS request), retain the digest 
challenge string, then send each subsequent request (including puts) 
with the appropriate auth header.

Now, I'm trying to go through the HttpAuthenticator code and figure 
out how to do that. If anyone has any experience with this I would 
appreciate hearing about it. I am fairly new to HttpClient.

Thanks for your input,
Jen
On Jul 13, 2004, at 3:34 AM, Michael Becke wrote:
Yes, HttpClient will buffer the content if you use 
CONTENT_LENGTH_AUTO.

Mike
On Jul 13, 2004, at 3:20 AM, Ingo Brunberg wrote:
The problem is that you are using chunked transfer encoding. This
prevents Httpclient to automatically buffer the content in memory and
the InputStream can only be read once.
The workaround is simply to provide the exact content-length.
Ingo
Hi,
I wonder if anyone could offer a suggestion for getting around an
exception I'm seeing.
I am writing a load test client that sends requests to a webdav 
server.
I have a putMethod which does the following:

			PutMethod method = new PutMethod(URIUtil.encodePathQuery(path));
			generateIfHeader(method);
			if (getGetContentType() != null  
!getGetContentType().equals())
method.setRequestHeader(Content-Type, getGetContentType());
			method.setRequestContentLength(PutMethod.CONTENT_LENGTH_CHUNKED);
			method.setRequestBody(bis);
			int statusCode = client.executeMethod(method);

bis is a BufferedInputStream.
This method works fine when sending requests using Basic
authentication. However, I want to use Digest authentication (I have
setAuthenticationPreemptive set to false). When sending the request
using Digest, I get the exception:
org.apache.commons.httpclient.HttpException: Unbuffered entity
enclosing request can not be repeated.
In looking at the code, it appears that
EntityEnclosingMethod.writeRequestBody does not cache the request 
body.
So, when the request is resent (with the digest auth header), the
contentCache is null, thus the exception.

Does anyone know of a way around this?
Thanks,
Jennifer

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


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


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


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

Re: Wire log to Log4J logger.

[Michael Becke]

Hi Eric,
I would suggest posting this question to the commons-logging and tomcat  
folks.  This one is pretty well out of our scope.

Mike
On Jul 11, 2004, at 9:16 PM, Eric Bloch wrote:
Hey Folks,
I'm having trouble making httpclient 2.0 use log4j logging inside  
Tomcat5 (when running against java 1.4).  Seems as though tomcat5  
makes some call to the the commons logger early on (see below).   
Tomcat5 doesn't come with log4j... so the commons logging default log  
factory implementation picks up the jdk14 logger for tomcat as you'd  
expect.

I'm guessing that somehow when my webapp comes up... the commons  
logger fails to look for log4j in my WEB-INF/lib.  This feels like one  
of the class-loader disagreements that I've seen related to  
java/commons-logging and the servlet spec.  That is, my webapp is  
getting tomcat's copy of the default log factor impl, instead of its  
own.

Fwiw, this is a stack from early tomcat initialization:
LogFactoryImpl.getLogClassName() line: 331
LogFactoryImpl.getLogConstructor() line: 368
LogFactoryImpl.newInstance(String) line: 529
LogFactoryImpl.getInstance(String) line: 235
LogFactoryImpl.getInstance(Class) line: 209
LogFactory.getLog(Class) line: 351
JdkCompat.clinit() line: 53
StandardClassLoader.clinit() line: 207
ClassLoaderFactory.createClassLoader(File[], File[], URL[],  
ClassLoader) line: 189
Bootstrap.createClassLoader(String, ClassLoader) line: 160
Bootstrap.initClassLoaders() line: 104
Bootstrap.init() line: 193
Bootstrap.main(String[]) line: 399

And this is a stack where my initial use of the httpclient ends up  
picking up the JDK14 logger even though my webapp has log4j in it's  
WEB-INF/lib:

Jdk14Logger.init(String) line: 50
NativeConstructorAccessorImpl.newInstance0(Constructor, Object[])  
line: not available [native method]
NativeConstructorAccessorImpl.newInstance(Object[]) line: 39
DelegatingConstructorAccessorImpl.newInstance(Object[]) line: 27
Constructor.newInstance(Object[]) line: 274
LogFactoryImpl.newInstance(String) line: 529
LogFactoryImpl.getInstance(String) line: 235
LogFactoryImpl.getInstance(Class) line: 209
LogFactory.getLog(Class) line: 351
MultiThreadedHttpConnectionManager.clinit() line: 98
.
.
.


It isn't an option for me to put touch any of the jars inside the  
container.  And I'd like to force httpclient to use log4j when it's  
used within my webapp.  This was working fine, fyi, in tomcat4.

Any clues/advice?
Thanks!
-Eric
Michael Becke wrote:
Hi John,
HttpClient uses commons-logging which defaults to Log4j when it is   
present on the classpath.  You can enable wire logging by setting the  
 logger httpclient.wire to DEBUG.  This can be done using any of   
Log4j's standard configuration methods.
Mike
On May 24, 2004, at 10:07 AM, John Melody wrote:
Is there a way to configure the wire log to go to a Log4J log   
configured
for the application.

I have configured Log4J as my application logger and I would like to  
 send
the
Httpclient wire log to the same file. Currently it is set up as the
following -

System.setProperty(org.apache.commons.logging.simplelog.log.httpclie 
nt .wire
, debug);
which sends the wire log to the console.

Is it possible to configure this so that all the logging output   
including
the
wire log would go to my log4J application log?

thanks for any help,
regards, John.

John Melody
SyberNet Ltd.
Galway Business Park,
Dangan,
Galway.
Tel. No. +353 91 514400
Fax. NO. +353 91 514409
Mobile - 087-2345847
-
To unsubscribe, e-mail:   
[EMAIL PROTECTED]
For additional commands, e-mail:   
[EMAIL PROTECTED]

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


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

Re: HttpRecoverableException: failed to attemt retry

[Michael Becke]

Hi Daniele,
I am not familiar with slide and cannot say if it is compatible with 
HttpClient 2.0.  You might want to check with the slide folks.  Assuming 
that HttpClient 2.0 works with slide, we will be better able to help if 
you post the exception message that you are seeing.

Mike
Daniele Madama wrote:
Hi,
I'm writing a webapplication that use slide-webdavclient, I put also 
http-client 2.0 in the classpath, but I got some HttpRecoverableException 
when execute put, proppatch or propfind method. I follow http-client tutorial 
and I implement retry with 3 attempts; unfortunately this isn't my solution :
(. I continue to get HttpRecoverableException and now I don't known to put my 
hands!

Anyone have an idea or a solution??
Tnks for the reply.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: DO NOT REPLY [Bug 29636] - Setting different MAX_HOST_CONNECTION values per host using a single MultiThreadedHttpConnectionManager

[Michael Becke]

Oops.  I forgot to run the unit tests.  I'll take care of the NPE and 
try again.

Mike
On Jul 7, 2004, at 5:46 PM, [EMAIL PROTECTED] wrote:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=29636.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=29636
Setting different MAX_HOST_CONNECTION values per host using a single 
MultiThreadedHttpConnectionManager



--- Additional Comments From [EMAIL PROTECTED]  2004-07-07 21:46 
---
Mike,
It looks like getParameter(MAX_HOST_CONNECTIONS) can return null and 
cause a NPE.

Map m = (Map) getParameter(MAX_HOST_CONNECTIONS);
Integer max = (Integer) m.get(hostConfiguration);
I currently get over a dozen testcases failing on me with the patch 
applied

Otherwise looks good
Oleg
-
To unsubscribe, e-mail: 
[EMAIL PROTECTED]
For additional commands, e-mail: 
[EMAIL PROTECTED]


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

Re: POST and UTF-8

[Michael Becke]

Hi Grant,
The PostMethod contains support for setting form parameters.  Please 
take a look at PostMethod.addParameter(), PostMethod.setParameter() and 
http://jakarta.apache.org/commons/httpclient/methods/post.html.  When 
using these parameters you will want to set the content type to 
application/x-www-form-urlencoded; charset=UTF-8.

Mike
On Jul 6, 2004, at 4:52 PM, Grant Ingersoll wrote:
Hi,
Have searched the archives, but cannot find an answer on how to submit 
a POST that has form parameters that need to be encoded in UTF-8.  I 
am setting the Content-Type request header, but am unsure as how to 
set the request body.  Do I use a ByteArrayInputStream?  Does anyone 
have an example of how to do this as far as putting FORM parameters 
into the IS?  Do I do something like:

byte [] bytes = myKey=myValue.getBytes(UTF-8);
ByteArrayInputStream is = new ByteArrayInputStream(bytes);
postMethod.setRequestBody(is);
---
I have 4 such parameters that need to be sent.  Any help is 
appreciated.

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


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

Re: getConectionsInUse Question

[Michael Becke]

Hi Juan,
Yes, you are correct.  getConnectionsIsUse() is slightly misleading.  
Please take a look at bug #29383 
http://issues.apache.org/bugzilla/show_bug.cgi?id=29383 for some more 
details on this one.  This bug contains a patch that should resolve the 
problem.  Please let us know if you have any other thoughts, and if 
this patch fixes the problem for you.

Mike
On Jun 21, 2004, at 11:05 AM, Juan Pedro López Sáez wrote:
Hello.
Testing the MultiThreadedHttpConnectionManager, I have realized that 
the
number retrieved by calling the getConnectionsInUse methods is
independent whether the HTTP connection is actually opened or not.

So it's seems to be a counter for the number of connections in pool
instead of a counter of really opened connections.
Is this true? Is there any way to know the number of really opened
connections?
I tested this by setting the HTTP header Connection: close. I could
see that HttpConnection.close() and 
HttpConnection.closeSockedAndStreams
are called, so I guess connections in pool are really closed.

Thank you very much.
Juan Pedro Lopez

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


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

Re: Connection Keep Alive feature and multi threaded connection manager

[Michael Becke]

Hi Juan,
If the server does not support persistent connections then, as you say, 
reusing connections will not help performance much.  The only benefit I 
can see is in the reduction of objects being created.  Reusing the 
connection manager will reduce the instances of 
SimpleHttpConnectionManager and HttpConnection that are created.  Also, 
if in the future, if the server began supporting persistent connections 
then you would be ahead of the game.

Mike
On Jun 17, 2004, at 5:04 AM, Juan Pedro López Sáez wrote:
Hello everybody.
One of my applications is using HttpClient to connect to an external
server and send some data.
It's a multi threaded application in which every new thread creates a
HttpClient object with the simple connection manager to do its job.
As a general rule, I want to switch to the multi threaded manager in
most of my applications to improve the overall performance.
I've recently found out that the server closes every HTTP connection
after sending back the response to my post request.
So in this scenario, I guess the connection pool supplied by the multi
threaded manager won't improve anything when connecting to that server.
The question is: is there any other advantage in using the multi
threaded manager instead of the simple one in this situation or should 
I
leave things unchanged in this application?

Thank you very much.
Juan Pedro Lopez
-
-
To unsubscribe, e-mail: 
[EMAIL PROTECTED]
For additional commands, e-mail: 
[EMAIL PROTECTED]


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

Re: Some question about the multithreaded manager

[Michael Becke]

Hello Juan,
Sounds like you've thought this through pretty well.  Your overall plan 
sound good.  Please find my specific comments below:

- Is it possible to set different values for MAX_HOST_CONNECTION, in a
per HOST basis? My application has to connect to some host and I'd like
to set different values for everyone. Maybe using different HttpClient
objects, each one with a different manager?
Currently it is not possible to set different values per host.  The only 
way to accomplish this would be with different connection managers, one 
per host.  Please file a enhancement request in bugzilla for this, and I 
will look into adding it for HttpClient 3.0.

- What happens if MAX_HOST_CONNECTION is exceeded and
HttpClient.executeMethod(HttpMethod) is called again? Can I wait until a
connection is released?
This will cause the calling thread to block until a connection is 
available.  This wait time can be configured using 
HttpClient.setHttpConnectionFactoryTimeout().

- Is MAX_TOTAL_CONNECTION a global value per application or just per
manager? I'd also like to set independent different values depending on
some cases. Is it possible, anyway?
It is a per connection manager variable.
- Is there any trouble in using one HttpClient object with the
multithreaded manager and another one with the simple manager, provided
that both objects will hit different hosts?
Nope, no problem here.  They could even hit the same host if you like. 
There is no enforced relationship between instances of connection managers.

AFAIK, HostConfiguration class has nothing to do with the relative path
of an URI, I mean, it just stores information about the host IP and
port. Is it right? 
This is correct.  The HostConfiguration is mean to encompass all 
information required to describe a connection path to a particular host. 
 This includes remote host/port, protocol (HTTP, HTTPS, etc.), proxy 
host/port, and local host/port.  It does not include information about 
specific resources on the server, these are specified on a per method 
basis via the request URI(path/query components).

Finally, I'd like you to tell me if the following code structure is
aproppiate:
...
I want every ConnectionThread to share the same HttpClient, so that I
can take advantage of the multithreaded manager and its connection pool.
This sounds like a reasonable scenario.  I believe that a number of 
HttpClient users are doing similar things.  The only other item to 
consider is the HttpState.  The HttpState stores credentials and cookies 
used for processing requests.  Depending on what each of the threads is 
doing you may or may not want to use the same HttpState for all requests.

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

Re: Invalid RSA modulus size

[Michael Becke]

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

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

Mike
On Jun 14, 2004, at 10:19 PM, Tim Wild wrote:
Thanks for that Oleg. Using JDK 1.5.0b2 does indeed get past the 
invalid modulus size error. I've got another error message now: 
javax.net.ssl.SSLHandshakeException: 
sun.security.validator.ValidatorException: No trusted certificate 
found.

My apache server has a certificate from a certification authority 
called Digital Identity, in New Zealand. They have a root certificate 
authority, then two sub-CAs (perhaps called chained CAs). My server 
certificate and client certificate are chained under one of these 
sub-CAs. When I use Mozilla it all works perfectly, it requests the 
certificate, the browser presents it, and I can see the page I 
requested.

When I try the same thing using Java I get the error message above. I 
have a keystore with just my client certiciate in it (nothing else), 
the same client certificate that works in Mozilla. I know it's finding 
the certificate because i'm having Java print out the alias of the 
certificate it's using. The CA certs are in the cacerts file of the 
JDK1.5 i'm using.

Does anyone have any idea why i'm getting this error? Any thoughts or 
ideas about how to go forward or things to investigate would be 
welcome.

Thanks
Tim
Oleg Kalnichevski wrote:
Tim,
This is believed to be a limitation of all Sun's JCE/JSSE
implementations up to Java version 1.5. You can try testing your
application with Java 1.5-b2 to see if the problem has indeed been
fixed. Alternatively consider using IBM Java 1.4 or 3rd party JCE/JSSE
implementations which _may_ not exhibit the same limitation
HTH
Oleg
On Sat, 2004-06-12 at 05:36, Tim Wild wrote:
Hi,
I'm using HttpClient to connect to an apache server that requires 
certificates. When I use client and server certificates from my own 
CA with 1024 bit keys it works perfectly. When I get a commercial 
certificate with a longer key (4096 bits), I get the following error 
(full message below) when I connect to apache:

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

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

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

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



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


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


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

Re: Deprecate HttpMethod#recycle

[Michael Becke]

Most definitely +1.
Mike
On Jun 11, 2004, at 4:34 AM, Kalnichevski, Oleg wrote:
Folks,
I suggest HttpMethod#recycle method be deprecated in 2.0 and 3.0. This  
has already been suggested by Eric a while ago. We should have  
listened

Oleg
*** 

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


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


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

Re: HttpClient 2.0 problems

[Michael Becke]

It can also be caused by more that one method using the same connection  
simultaneously.  For example if two threads are using the same  
HttpClient instance with the SimpleHttpConnectionManager.

Mike
On Jun 11, 2004, at 4:27 AM, Kalnichevski, Oleg wrote:
Arturo,
unable to find line starting with 'HTTP' error is reported
(1) when response (status line, to be exact) sent by the server is  
malformed
(2) if HttpClient fails to correctly parse the status line sent by the  
server
(3) when the target server accepts connection but then fails to send  
any response back and simply drops the connection on unsuspecting  
HttpClient

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

Hope this helps
Oleg

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


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

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

  boolean retry=false;
  do{
statusCode = Procesa_Get_Url(url, client, config, state,
urlToConnect2, respHTML1);
if (statusCode != -1  urlToConnect2.toString().trim() !=   

urlToConnect2.toString().trim().length() != 0){
retry=true;}
  }while (retry==false);

 private int Procesa_Get_Url(String urlProc, HttpClient clientProc,
 HostConfiguration configProc, HttpState stateProc, StringBuffer urlTC,
 StringBuffer respHTML) throws Exception {int statusCode=-1;
String redirectLocation=null;
clientProc.setTimeout(60*30*1000);
clientProc.setHttpConnectionFactoryTimeout(60*30*1000);
clientProc.setConnectionTimeout(60*30*1000);
//try{
  //URI uri = new URI(urlProc.toCharArray());
  URI uri = new URI(urlProc.toCharArray());
  HttpMethod method = new GetMethod(uri.toString());
  String schema = uri.getScheme();
  if ((schema == null) || (schema.equals())){
schema = http;
  }
  Protocol protocol = Protocol.getProtocol(schema);
  String host = uri.getHost();
  int port = uri.getPort();
  configProc.setHost(host,port,protocol);
   
configProc.setProxy(System.getProperty(http.proxyHost),Integer.parseI 
nt(System.getProperty(http.proxyPort,80)));
stateProc.setProxyCredentials(null, null,
new UsernamePasswordCredentials(
  System.getProperty(http.proxyUserName),
  System.getProperty(http.proxyPassword)));

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

} catch (HttpRecoverableException e) {
  method.recycle();
  method.releaseConnection();
  System.out.println(A recoverable exception occurred,
  retrying.   + e.getMessage());} catch
  (IOException e) {
  System.err.println(Failed to download file.);
  e.printStackTrace();
}catch (Exception e) {
  System.err.println(Errorsote.);
  e.printStackTrace();
}
  //}while (retry=false);
  if (statusCode == -1) {
System.err.println(Numero de Intentos: + attempt);
System.err.println(Failed to recover from exception.);
  }
  switch (statusCode){
case 200 :  stateProc.setCookiePolicy(CookiePolicy.RFC2109);
Cookie[] cookies =  stateProc.getCookies();
System.out.println(Present cookies: );
for (int i = 0; i  cookies.length; i++) {
  System.out.println( -  +
  cookies[i].toExternalForm()); 
}
urlTC.append(method.getURI().toString());
   

Re: DO NOT REPLY [Bug 29439] - Credentials ignored if realm specified in preemptive authentication

[Michael Becke]

Ooops.  I forgot to update the site last night.  I'm doing so now.
Mike
On Jun 9, 2004, at 6:00 AM, [EMAIL PROTECTED] wrote:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=29439.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=29439
Credentials ignored if realm specified in preemptive authentication
[EMAIL PROTECTED] changed:
   What|Removed |Added
--- 
-
   Severity|Normal  |Enhancement
 Status|NEW |ASSIGNED
   Target Milestone|--- |3.0 Alpha 2


--- Additional Comments From [EMAIL PROTECTED]  2004-06-09 09:59  
---
Philippe,
Just recently we have had a quite few complaints regarding the way  
preemptive
authentication is handled. The official HttpClient authentication  
guide has been
revised to clarify the gray areas in the 2.0 API primarily concerning  
the
prerequisites expected in order to make preemptive authentication  
functional.
Rather unfortunately the site has not been redeployed yet, so the  
updated
authentication guide is not available at the moment. You can see the  
xdoc source
 at the following location

http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/xdocs/ 
authentication.xml? 
rev=1.5.2.4only_with_tag=HTTPCLIENT_2_0_BRANCHview=markup

But I don't personally think it is defensive enough since it disable
preemptive auth and it could result in large performance degradation
since you have to repeat (multi-megabytes?) POST requests two times
to get through.
Preemptive authentication is not the best answer to this problem. The  
problem
can be much better addressed by using so called 'expect-continue'  
handshake. See
ExpectContinueMethod method's javadoc for details.

The entire authentication framework in HttpClient has been completely  
rewritten
for the 3.0 release. With HttpClient 3.0 one should already get a  
warning in
case of missing authentication credentials. Furthermore, it also  
provides a
better API for credentials assignment and retrieval. I will also try  
to come up
with a better way to assign default credentials. So, stay tuned

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


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

Re: Controlling Threads in Waiting

[Michael Becke]

Hi Satya,
There is no way to control the number of threads waiting in the 
MultiThreadedHttpConnectionManager.  It only allows configuring the 
number of connections available.  I would suggest controlling the total 
number of threads using a particular connection manager.  That way you 
can set a connection limit that is reasonable for the number of 
threads.

Mike
On Jun 9, 2004, at 9:49 PM, [EMAIL PROTECTED] wrote:
Hello All,
Is there is a direct way to control the maximum no of threads in 
waiting for a connection from the Connection Manager.
Thanks in advance for your openion.
--Satya

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


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

test

[Michael Becke]

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

HttpConnection and HttpState reuse problem

[Michael Becke]

Hi Himanshu,
HttpClient intentionally does not give direct access to the connections 
used to execute methods.  All connection management is handled by the 
HttpConnectionManagers and the HttpClient.  As Roland mentioned, if you 
need custom connection management you should consider implementing an 
HttpConnectionManager.  My guess is that the two included connection 
managers (SimpleHttpConnectionManager and 
MultiThreadedHttpConnectionManager) should suffice for your needs.

Mike
On Jun 3, 2004, at 12:24 PM, Himanshu Thube wrote:
Hi
In my class I need two connections to same host and different URL's. 
For connecting first time, I want to get the HttpState and 
HttpConnection. Later just execute the method using the same 
HttpConnection and HttpState.

However from API I found, to get the state I need to execute the 
method with HttpClient for the first time as only HttpClient is able 
to return the HttpState. For the later executions of GetMethod I am 
not able to reuse the HttpConnection used for first execution as 
HttpClient doesn't provide me a handle to the HttpConnection which it 
used for first execution.

My existing code is as follows :
*For first invocation *:
   httpsclient = new HttpClient();
   int statusCode = -1;
   String [] response=new String[2];  httpsget = new 
GetMethod(uri.toString());
   statusCode = httpsclient.executeMethod(httpsget);
   state=httpsclient.getState();

*For Later invocations : (now I have the HttpsState but no handle to 
HttpConnection used :( so have to create a new HttpConnection)*

if(con==null) {
   try {
   con=new HttpConnection(uri.getHost(), uri.getPort(), 
getProtocol());
   } catch (URIException e1) {
   e1.printStackTrace();
   }  }
   try {
   httpsget.recycle();
   httpsget.setPath(connectUrl);
   httpsget.execute(state, con);
   } catch (IOException e) {
   e.printStackTrace();
   }

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


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

Re: HttpConnection and HttpState reuse problem

[Michael Becke]

Hi Himanshu,
HttpClient intentionally does not give direct access to the connections 
used to execute methods.  All connection management is handled by the 
HttpConnectionManagers and the HttpClient.  As Roland mentioned, if you 
need custom connection management you should consider implementing an 
HttpConnectionManager.  My guess is that the two included connection 
managers (SimpleHttpConnectionManager and 
MultiThreadedHttpConnectionManager) should suffice for your needs.

Mike
On Jun 3, 2004, at 12:24 PM, Himanshu Thube wrote:
Hi
In my class I need two connections to same host and different URL's. 
For connecting first time, I want to get the HttpState and 
HttpConnection. Later just execute the method using the same 
HttpConnection and HttpState.

However from API I found, to get the state I need to execute the 
method with HttpClient for the first time as only HttpClient is able 
to return the HttpState. For the later executions of GetMethod I am 
not able to reuse the HttpConnection used for first execution as 
HttpClient doesn't provide me a handle to the HttpConnection which it 
used for first execution.

My existing code is as follows :
*For first invocation *:
   httpsclient = new HttpClient();
   int statusCode = -1;
   String [] response=new String[2];  httpsget = new 
GetMethod(uri.toString());
   statusCode = httpsclient.executeMethod(httpsget);
   state=httpsclient.getState();

*For Later invocations : (now I have the HttpsState but no handle to 
HttpConnection used :( so have to create a new HttpConnection)*

if(con==null) {
   try {
   con=new HttpConnection(uri.getHost(), uri.getPort(), 
getProtocol());
   } catch (URIException e1) {
   e1.printStackTrace();
   }  }
   try {
   httpsget.recycle();
   httpsget.setPath(connectUrl);
   httpsget.execute(state, con);
   } catch (IOException e) {
   e.printStackTrace();
   }

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


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

Re: Probem executing Query

[Michael Becke]

Hi Satya,
setQueryString() assumes that the content is already URL encoded and it 
is then sent as part of the request line, i.e.:

POST /path?QUERY_STRING  HTTP/1.1
My guess is that you want to send the query string as part of the 
message body.  You can do this with:

mehod.setRequestBody(userModel.getQueryString());
Mike
On Jun 3, 2004, at 7:13 PM, [EMAIL PROTECTED] wrote:
I am using the following code:
HttpClient client = new HttpClient(connMgr);
client.setHostConfiguration(hostConfig);
PostMethod method = new PostMethod(tokenURL);
method.setQueryString( userModel.getQueryString() );
client.executeMethod(method);
byte[] responseBody = method.getResponseBody();
method.releaseConnection();
The response I get is : Request format is invalid: .
--
However,  If I run the same query using the following code:
  con.setRequestMethod(POST);
  con.setDoOutput(true);
  con.setDoInput(true);
  OutputStreamWriter writer = new 
OutputStreamWriter(con.getOutputStream());
  writer.write( userModel.getQueryString() );
  writer.flush();
  writer.close();

  InputStream resultStream = con.getInputStream();
  BufferedReader reader = new BufferedReader(new 
InputStreamReader(resultStream));
  StringBuffer aResponse = new StringBuffer();
  String aLine = reader.readLine();

  while(aLine != null){
  aResponse.append(aLine);
  aLine = reader.readLine();
  }
  resultStream.close();
  releaseConnection(con);
  String retData = aResponse.toString();
I get the expected string as a response.
What I am doing wrong in using HttpClient?  Any Idea?.
-Satya
-
To unsubscribe, e-mail: 
[EMAIL PROTECTED]
For additional commands, e-mail: 
[EMAIL PROTECTED]


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

Re: Connection Accounting Problem

[Michael Becke]

Hi Roland,
Sounds like a good plan to me.  I will deprecate getConnectionsInUse() 
and replace it with a better name.  getConnectionsInPool() is good, 
perhaps also getConnectionsAllocated()?

For deleting connections I think we have two options.  One is to kill 
all closed connections.  The only problem here is that we will end up 
calling isOpen()-iStale() on all the connections.  Another possibility 
to is kill all connections that are currently not being used.  This 
would be all connections currently held by the connection manager.

Mike
Roland Weber wrote:
Hi Mike,
deprecate getConnectionsInUse(),
replace with getConnectionsInPool() ?
Introduce something like
garbageCollectConnections() or
deleteIdleConnections()
for people who really want to throw
away the closed connections ?
I'd stick with your option 1 until there
is a case where the other behavior is
actually needed.
cheers,
  Roland


Michael Becke [EMAIL PROTECTED]
01.06.2004 03:14
Please respond to Commons HttpClient Project
 
To: Commons HttpClient Project 
[EMAIL PROTECTED]
cc: 
Subject:Re: Connection Accounting Problem

Hi Satya,
Sorry for the slow response...  The number of connections in use does 
not get decremented in this case as no connections are actually being 
destroyed.  The connection manager still holds references to the same 
number of connections after closeIdleConnections() is called. 
connectionsInUse is meant to detail the number of connections that have 
been allocated, not the number that are open.  Given these semantics 
the behavior is correct I believe.

The next question is if this makes sense.  I see two possibilities here:
  1) Document getConnectionsInUse() to better describe the current 
behavior.
  2) Change closeIdleConnections() to delete closed connections.  This 
will require changes to the IdleConnectionHandler, so that we know 
which connections are closed.

Any suggestions or preferences?
Mike
On May 27, 2004, at 5:27 PM, [EMAIL PROTECTED] wrote:

After Calling
MultiThreadedHttpConnectionManager.closeIdleConnections(idleTime), the 
timedout connections are closed, however, connectinon count does not 
decrease.
Therefore, if I call 
MultiThreadedHttpConnectionManager.getConnectionsInUse(), I still get 
the same value as before calling closeIdleConnections(). After a bit 
of code browsing the problem seems to be in the following code:
public synchronized void closeIdleConnections(long idleTimeout) {
idleConnectionHandler.closeIdleConnections(idleTimeout);
}
Which does not decrease the number of connections after actually 
removing them.
The code should be:
public synchronized void closeIdleConnections(long idleTimeout) {
idleConnectionHandler.closeIdleConnections(idleTimeout);

//Now do the connection accounting (Pseudo code)
numConnections = idleConnectionHandler.getConnectionsCount();
//Also adjust the hostPool.numConnections
}
Any taker?
--Satya
-
To unsubscribe, e-mail: 
[EMAIL PROTECTED]
For additional commands, e-mail: 
[EMAIL PROTECTED]


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


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

Re: Connection Accounting Problem

[Michael Becke]

Hi Satya,
Sorry for the slow response...  The number of connections in use does 
not get decremented in this case as no connections are actually being 
destroyed.  The connection manager still holds references to the same 
number of connections after closeIdleConnections() is called.  
connectionsInUse is meant to detail the number of connections that have 
been allocated, not the number that are open.  Given these semantics 
the behavior is correct I believe.

The next question is if this makes sense.  I see two possibilities here:
 1) Document getConnectionsInUse() to better describe the current 
behavior.
 2) Change closeIdleConnections() to delete closed connections.  This 
will require changes to the IdleConnectionHandler, so that we know 
which connections are closed.

Any suggestions or preferences?
Mike
On May 27, 2004, at 5:27 PM, [EMAIL PROTECTED] wrote:
After Calling
MultiThreadedHttpConnectionManager.closeIdleConnections(idleTime), the 
timedout connections are closed, however, connectinon count does not 
decrease.
Therefore, if I call 
MultiThreadedHttpConnectionManager.getConnectionsInUse(), I still get 
the same value as before calling closeIdleConnections(). After a bit 
of code browsing the problem seems to be in the following code:
public synchronized void closeIdleConnections(long idleTimeout) {
 idleConnectionHandler.closeIdleConnections(idleTimeout);
}
Which does not decrease the number of connections after actually 
removing them.
The code should be:
public synchronized void closeIdleConnections(long idleTimeout) {
 idleConnectionHandler.closeIdleConnections(idleTimeout);

 //Now do the connection accounting (Pseudo code)
 numConnections = idleConnectionHandler.getConnectionsCount();
 //Also adjust the hostPool.numConnections
}
Any taker?
--Satya
-
To unsubscribe, e-mail: 
[EMAIL PROTECTED]
For additional commands, e-mail: 
[EMAIL PROTECTED]


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

Re: HttpClient problems

[Michael Becke]

Why is the connection closed here? Who is doing this? The response has 
not been read yet!
This is because of the exception when writing the request.  
HtttpMethodBase closes connections on exception.

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

Re: HttpClient problems

[Michael Becke]

Hi Paul,
Two quick questions.
 - Have you set  
MultiThreadedHttpConnectionManager.setConnectionStaleCheckingEnabled()  
to false?  If so this could be causing the problem.

 - It seems that the server is closing the request in mid stream.  Have  
you checked the IIS logs?  There might be something there.

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

=
Thanks a lot for the info.
Ortwin Glück wrote:

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


Does anybody know what causes the SocketException ?

Not yet, but we're gonna find out for you :-)
Please produce a wirelog and send the section with the request /  
response immediately preceding the exception.
For instructions about how to make a wirelog please see our Logging  
Guide:
http://jakarta.apache.org/commons/httpclient/logging.html

Please note that wire logging will slow down your application  
considerably! This is escpecially bad, because the problem you are  
experiencing seems to happen randomly. Please make sure you disable  
logging after you have successfully captured the output.


Is it becos I didn't
set a higher maximum connection per host using  
setMaxConnectionsPerHost on the MultiThreadedHttpConnectionManager  
object ?

Probably not - just doesn't look like it.
Pls help. This is urgent as I am currently using it on a production  
system.

You are welcome. Maybe we should start offering commercial support  
and make A LOT of money :-)

Re: ConnectionTimeoutException thrown without waiting.

[Michael Becke]

Mike, Any idea why closed connection is considered stale?
snip protected boolean isStale() { boolean isStale = true; if
(isOpen) { // the connection is open, but now we have to see if we
can read it // assume the connection is not stale. isStale = false; 
/snip
It's just poor logging.
public boolean isOpen() {
if (used  isStaleCheckingEnabled()  isStale()) {
LOG.debug(Connection is stale, closing...);
close();
}
return isOpen;
}
isOpen() does not differentiate between stale and closed.  If the 
connection is closed isStale() will return true.  In the case at hand it 
appears that the connections are actually closed, but the logging makes 
that unclear.

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

Re: Roundtrip timeout

[Michael Becke]

Hi Christopher,
HttpClient.setTimeout() is what you are looking for.
Mike
On May 27, 2004, at 1:26 PM, Foran, Christopher wrote:

Is there a way of setting SO_TIMEOUT on the socket read?  This his how 
the previous connection class I was using simulated a roundtrip 
timeout. Thanks.

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

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

Re: retrieved wired code for Unicode

[Michael Becke]

Hello KMKU,
The wire log converts all content to ASCII, and encodes all non-ASCII  
characters to the format you've seen.  The actual content of the HTTP  
response (available via HttpMethod.getResponseBody*() methods)  
correctly handles charsets.  The wire log is just meant for debugging.

Mike
On May 25, 2004, at 2:24 AM, K.M. Ku wrote:
HI,
I am using commons-httpclient-2.0.
 This UTF8 web page gives wired code:
http://springerlink.metapress.com/app/home/journal.asp? 
wasp=c28459nnmjcjwhf9
rl rlreferrer=parentbackto=browsepublicationsresults,21,497;

 It should show : J. Schön, F. Göritz, J. Streich, et al.
 However, the wire log shows that the Unicode codes are  
[0xfffd][0xfffd] .

 [2004-05-25 12:59:18,883] [DEBUG] [main] httpclient.wire:  
J. S
 ch[0xfffd][0xfffd]n, F. G[0xfffd][0xfffd]ritz, J. Streich, Iet
al./I[\r][\n]
 Can someone suggest me what the problem is?
 Regards,
 KMKU

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


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

Re: client certificates: contribution

[Michael Becke]

Tim,
I would actually suggest creating a new bug in Bugzilla and attaching 
the contribution there.  That way there is a public record of where the 
code came from.

As Ortwin mentions a CLA, though actually not required, would be 
desirable.

Mike
On May 25, 2004, at 2:51 AM, Ortwin Glück wrote:

Tim Wild wrote:
I was thinking more the cvs contrib directory, how would I get it in 
there?
Tim,
you would need write access to CVS (i.e. be a committer to the 
HttpClient) project to directly import your code. Best is, to send 
your code to one of the committers, as the list tends to strip 
attachments off ones emails. To accept contributed code it is also 
required that you file a CLA [1] with the ASF.

[1] CLA: http://www.apache.org/licenses/index.html#clas
-
To unsubscribe, e-mail: 
[EMAIL PROTECTED]
For additional commands, e-mail: 
[EMAIL PROTECTED]


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

Re: Logging messages to a file

[Michael Becke]

Hi Rob,
Commons logging (the logging framework used by HttpClient) does not  
natively support anything more complicated than just writing to  
console.  Fortunately it can make use of other logging systems like  
log4j or java.util.logging.  Please take a look at the commons-logging  
site http://jakarta.apache.org/commons/logging/ and log4j  
http://logging.apache.org/log4j/docs/ for some more detail.

Mike
On May 21, 2004, at 6:44 PM, Robert Stagner wrote:
I'm new to this list, so forgive me if my question seems a bit off  
topic.  I'm in the midst of developing an application using  
commons-httpclient, and I've integrated the following code to include  
debug level logging:

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

With this code in place, I'm receiving the expected debug level  
messages at the console.  However, my question is thisis there any  
way to redirect this output to a file using some sort of system  
property (similar to those used above)??  How could this be done??

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


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

Re: Posting XML over authenticated connection using SSL

[Michael Becke]

I think the problem is that the realm is being specified.  Trying using 
null as the realm: httpState.setCredentials(null, somehost, creds);

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

client.getState().setAuthenticationPreemptive(true);
client.getState().setCredentials(realm, host, upc);
 
Try this instead
httpState.setAuthenticationPreemptive(true);
httpState.setCredentials(realm, host, upc);
status = client.executeMethod(hostConfiguration, method, httpState);
HTH
Oleg

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

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

Any ideas?
Regards
Lee Francis
-
To unsubscribe, e-mail: 
[EMAIL PROTECTED]
For additional commands, e-mail: 
[EMAIL PROTECTED]

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

Re: 3.0 alpha1 build

[Michael Becke]

What in the Javadocs needs fixing?
Mike
On May 17, 2004, at 7:58 AM, Kalnichevski, Oleg wrote:
Almost forgot. Javadocs need fixing. I'll take care of the problem  
tonight unless someone beats me to it

Oleg
-Original Message-
From: Michael Becke [mailto:[EMAIL PROTECTED]
Sent: Monday, May 17, 2004 6:11
To: Commons HttpClient Project
Subject: 3.0 alpha1 build
I've uploaded the 3.0 alpha1 build to my apache account
http://www.apache.org/~mbecke/httpclient-3.0-alpha1/.  Please have a
look and let me know if I've missed anything.  This release was created
with JDK1.3.1 since it seems that Maven RC2 does not work with 1.2.2.
I don't think this will cause any issues, but if anyone is using 1.2.2
please give it a shot.  This is also the first time I've signed a
release.  My public key is in the KEYS file so please try that out as
well.
My plan is to finish this off tomorrow night and post the release.  I
was thinking of leaving the 2.0 docs as the main HttpClient page, and
just adding a link to the 3.0 version in another directory.
Mike
-
To unsubscribe, e-mail:  
[EMAIL PROTECTED]
For additional commands, e-mail:  
[EMAIL PROTECTED]

*** 

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


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


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

[ANNOUNCE] Release of Commons HttpClient 3.0 Alpha 1

[Michael Becke]

We are pleased to announce the first HttpClient 3.0 release.  
HttpClient 3.0 provides a wealth of features and enhancements that did 
not make it into the 2.0 release.  We have attempted to preserve API 
compatibility as much as possible. In a relatively few cases API 
compatibility with HttpClient 2.0 could not maintained.

Noteworthy enhancements include:
  -  New preference architecture
  -  Improved exception handling framework
  -  Granular non-standards configuration and tracking
  -  Improved authentication framework
  -  Plug-in mechanism for authentication modules
  -  Cookie specification plug-in mechanism
  -  Cross-site redirect support
This release is targeted at projects already using HttpClient 2.0.  Now 
is the time to evaluate HttpClient 3.0 and give us some feedback, 
critique or other thought on the new API. Please feel free to file 
requests for additional features.

Please visit the HttpClient Web site 
http://jakarta.apache.org/commons/httpclient/ for more information.

Thank you,
Commons HttpClient Development Team
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[VOTE][RESULT] 3.0 alpha 1 release

[Michael Becke]

The vote to release 3.0 alpha 1 has passed with the following votes:
+1 Michael Becke - mbecke at apache.org
+1 Oleg Kalnichevski - olegk at apache.org
+0 Ortwin Glück - oglueck at apache.org
+1 Adrian Sutton - adrian at apache.org
+0 Mohammad Rezaei - mohammad.rezaei at gs.com
vote thread:
http://nagoya.apache.org/eyebrowse/BrowseList?listName=commons- 
[EMAIL PROTECTED]by=threadfrom=767418

I will tag HEAD and proceed with a release.
Mike
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE][RESULT] 3.0 alpha 1 release

[Michael Becke]

To be honest, I'm not sure.  I will send again just in case.
Mike
On May 16, 2004, at 9:24 PM, Adrian Sutton wrote:
Does this need to be CC'd to pmc?  It would probably be a good idea  
anyway.

Thanks for your efforts Mike.
Regards,
Adrian Sutton.
On 17/05/2004, at 10:36 AM, Michael Becke wrote:
The vote to release 3.0 alpha 1 has passed with the following votes:
+1 Michael Becke - mbecke at apache.org
+1 Oleg Kalnichevski - olegk at apache.org
+0 Ortwin Glück - oglueck at apache.org
+1 Adrian Sutton - adrian at apache.org
+0 Mohammad Rezaei - mohammad.rezaei at gs.com
vote thread:
http://nagoya.apache.org/eyebrowse/BrowseList?listName=commons- 
[EMAIL PROTECTED]by=threadfrom=767418

I will tag HEAD and proceed with a release.
Mike
-
To unsubscribe, e-mail:  
[EMAIL PROTECTED]
For additional commands, e-mail:  
[EMAIL PROTECTED]

--
Intencha tomorrow's technology today
Ph: 38478913 0422236329
Suite 8/29 Oatland Crescent
Holland Park West 4121
Australia QLD
www.intencha.com
-
To unsubscribe, e-mail:  
[EMAIL PROTECTED]
For additional commands, e-mail:  
[EMAIL PROTECTED]


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

[VOTE][RESULT] HttpClient 3.0 alpha 1 release

[Michael Becke]

The vote to release 3.0 alpha 1 has passed with the following votes:
+1 Michael Becke - mbecke at apache.org
+1 Oleg Kalnichevski - olegk at apache.org
+0 Ortwin Glück - oglueck at apache.org
+1 Adrian Sutton - adrian at apache.org
+0 Mohammad Rezaei - mohammad.rezaei at gs.com
vote thread:
http://nagoya.apache.org/eyebrowse/BrowseList?listName=commons- 
[EMAIL PROTECTED]by=threadfrom=767418

I will tag HEAD and proceed with a release.
Mike
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

3.0 alpha1 build

[Michael Becke]

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

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

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