Re: java.io.StreamCorruptedException when a sending huge java object...
Suraj,
The problem is not caused by HttpClient, but because you are using the
IO API incorrectly.
Suraj Natarajan wrote:
int len = httpRequest.getContentLength();
InputStream is = httpRequest.getInputStream();
byte[] b = new byte[len] ;
// read the entire content in one shot
is.read(b);
Please read the API Doc of the read method. The method does not
guarantee to read a specific number of bytes, but it will return the
number of bytes read as an int. You must repeatedly read from the stream
until read() returns -1.
// construct the java object from the byte[]
deserialize(b) ;
If the request content length is big around 25K then a
java.io.StreamCorruptedException is thrown during deserialization. This
only happens when the content length is big.
If the stream is read using the code below then it works fine even for
huge content length.
InputStream is = httpRequest.getInputStream();
ByteArrayOutputStream baos = new ByteArrayOutputStream();
while ((read = bis.read(buffer)) != -1) {
baos.write(buffer, 0, read);
}
deserialize(baos.toByteArray());
This is exactly the correct way of reading from a stream.
Can someone please explain the problem and is there a better way do
this?
Thanks in advance.
YAW
Ortwin
--
[web] http://www.odi.ch/
[blog] http://www.odi.ch/weblog/
[pgp] key 0x81CF3416
finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to ensure socket reuse on client side?
On the HttpComponents front page it says: Jakarta HttpComponents project is charged with developing and maintaining Commons HttpClient. Commons HttpClient 3 series will be maintained until Jakarta HttpClient 4 is deemed stable enough to supersede it for use in production. This text is indeed not very clear. I will add some more text to the front page to steer new users into the right direction. Ortwin [EMAIL PROTECTED] wrote: Yes, it does fix the problem. Thanks for the help. I remember reading that we need to consume the entire response body (error or no error) so that connection can be used (on the Sun side). It is confirmed here. As far the second question about why HttpCore than HttpClient 3.1; I guess it is about the confusion and lack of clarity (Jakarta side does not help much too) - I am unaware which is the latest project which will be maintained in future. My impression is it is HttpCore. I may be wrong here. While I was waiting for a clue on HttpCore issue, I got things tested on HttpClient 3.1 too. I can use any of these two as advised. Socket reuse is my goal (since our application talks to lot of network devices). Once again thanks for the help. -- This message was sent on behalf of [EMAIL PROTECTED] at openSubscriber.com http://www.opensubscriber.com/message/httpclient-dev@jakarta.apache.org/5314835.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- [web] http://www.odi.ch/ [blog] http://www.odi.ch/weblog/ [pgp] key 0x81CF3416 finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ArrayIndexOutOfBoundsException in CookieSpecBase
Oleg Kalnichevski wrote: Tim, I do not see how possibly HttpClient could be causing LinkedList#toArray to throw an ArrayIndexOutOfBoundsException exception in this case. In this particular case I am more inclined to suspect a bug in Sun's Java Runtime Library. If you knew what cookies HttpClient was trying to match against which target host, I might be able to reproduce the problem locally. Oleg It could be a concurrency problem. Call toArray while modifiying the list and it may happen? Just an idea Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HTTPClient 3.0.1] Bug: Multipart posts with files named using UTF-8 characters
Guys, Look at RFC 2047 which updates RFC 1521. This method is quite popular in E-Mail traffic. Maybe real-world HTTP servers and clients support it? Odi Oleg Kalnichevski wrote: On Thu, 2006-10-19 at 14:29 +0200, Tumidajewicz, Przemyslaw wrote: Hello everyone, First post here, hope I'm doing it right ;) I've been having problems with sending multipart posts containing files named using UTF-8 characters - all non-ASCII characters are turned into question marks. I've tried to specify the charset when creating the FilePart like this FilePart fp = new FilePart(name, file, null, UTF-8); as well as setting the charset later on like this fp.setCharSet(UTF-8); with no result. So I took a deeper look at the HttpClient code (thank god for open source!) and found that the loss of special characters happens in the FilePart.sendDispositionHeader method, at line out.write(EncodingUtil.getAsciiBytes(filename)); where the filename is forced to fit into the US-ASCII charset. Przemyslaw, This behavior is in line with the requirements of the MIME specification as outlined in RFC 1521 and RFC 1522. The use of non-ASCII characters in MIME headers is not permitted. One is supposed to escape non-ASCII characters using BASE64 or Quoted-Printable encoding. See this feature request for details https://issues.apache.org/jira/browse/HTTPCLIENT-293 Oleg My workaround for this problem is to substitute the above line with a charset-aware version: out.write(EncodingUtil.getBytes(filename, getCharSet())); but I'm not sure if it's the correct way to do it. What I'm quite sure of at this point is that it works for UTF-8 and results are consistent with what I get out of IE6 when posting the same file using a form like this: form action=http://localhost:1235; method=POST enctype=multipart/form-data accept-charset=UTF-8 input type=file name=file/input input type=submit/input /form It's also parsed correctly by FileUpload 1.1. I've had a look at the HTTPClient 3.1-alpha1 source and the problematic line in FilePart looks the same - which means that either my fix is a heresy and/or there is a better way of doing this - or that this bug has not been reported before (I failed to find anything on this in the archive). Please let me know if this is the right way of fixing this problem and if so, will this fix make it into HTTPClient 3.1 Thanks and best regards! --Przemek - 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] -- [web] http://www.odi.ch/ [blog] http://www.odi.ch/weblog/ [pgp] key 0x81CF3416 finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons HttpClient 3.1 BETA1
+1 Oleg Kalnichevski wrote: I propose that we mark the latest code in SVN trunk as 3.1-BETA1 and proceed with a release. Please vote as follows: -- Vote: HttpClient 3.1-BETA1 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: Using HttpClient for sender and HttpServlet for receiver for parameters
-- client
NameValuePair[] data = new NameValuePair[] {
new NameValuePair(surname, Lee),
new NameValuePair(name, Wai See)
};
-- servlet
String surname = request.getParameter(surname);
String name = request.getParameter(name);
Hope that helps
Ortwin
Lee Wai See wrote:
Hi,
I have the following situation which I hope someone would be able to help me
with.
On the sender side, I am using HttpClient and have these few lines:
HttpClient httpClient = new HttpClient();
postMethod.addParameters (data);// data is of type
NameValuePair[]
httpClient.executeMethod(postMethod);
On the receiver side, I need to use the javax.servlet.http.HttpServlet with
the HttpServletRequest req. How can I get the parameters of NameValuePair[].
If I do a req.getParameter(), I will only get the first element of the
NameValuePair[].
I want to get all the elements of NameValuePair[]. How can I go about doing
it? It would be greatly appreciated if someone could guide me in this.
Thanks in advance.
Regards,
Lee Wai See
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.12.9/457 - Release Date: 9/26/2006
--
[web] http://www.odi.ch/
[blog] http://www.odi.ch/weblog/
[pgp] key 0x81CF3416
finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Board Report
Oleg Kalnichevski wrote: On Tue, 2006-09-12 at 10:50 +0200, Ortwin Glück wrote: Oleg, Mike, I have added a section to the board report at http://wiki.apache.org/jakarta/JakartaBoardReport-September2006 Please review and modify to your liking. Cheers Odi Hey Odi, Many thanks for having taken care of that. One thing, though. You should give Roland his due credit. HttpAsync is his baby. Oleg Thanks, Oleg. I must be half asleep still... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r434476
I dislike unnecessary public modifiers in interfaces too. my 0.05 CHF Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javax.net.ssl.SSLHandshakeException as a result of new GetMethod(/) ?
Guy,
Please provide a wirelog of the two requests.
Ortwin
Guy wrote:
Hi all,
i have written an application that checks https connections. I use the
HTTPClient 3.0.1 as described in the SSL guide
Protocol myhttps = new Protocol(https, new MySSLSocketFactory(), 443);
HttpClient httpclient = new HttpClient();
httpclient.getHostConfiguration().setHost(myHost, myPort, myhttps);
GetMethod httpget = new GetMethod(myObject);
try {
httpclient.executeMethod(httpget);
byte[] repsonse = getResponseBody();
System.out.println(httpget.getStatusLine());
} finally {
httpget.releaseConnection();
}
i have two versions of the MySSLSocketFactory: one that does not use a
truststore (accepting any certificate) and one that does.
i have the following parameters to set:
myHost, myPort, truststore (used to determine which version of the
MySSLSocketFactory to use), truststorepassword and myObject.
In the case i set myObject to / i get no exception, in case i set
myObject to /index.html i get the following exception:
javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to
find valid certification path to requested target
The code works fine for other hosts and the result does not change
when using the other version of MySSLSocketFactory: the value of
myObject determines the exception (if the host experiences this
problem)
I am stunned because the certificates are valid and are in the
truststore (if they are used)
Any suggestion or help would be appreciated
--
[web] http://www.odi.ch/
[blog] http://www.odi.ch/weblog/
[pgp] key 0x81CF3416
finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: unable to find line starting with HTTP
Chwang, You should produce a wirelog to see the real traffic. This error message is caused by a misbehaviour of the server. It can be due to a wrong Content-Length header in kept-alive connections for instance. http://jakarta.apache.org/commons/httpclient/logging.html Cheers Ortwin Chaohua Wang wrote: Hi, Folks, I am using HttpClient 3.1, The code is simple: HttpClient client = new HttpClient(); GetMethod method = new GetMethod( myURL ); byte[] responseBody = method.getResponseBody(); When I sent a short a url string with few parameters , it works fine. But when I sent a very long url string with too many parameters, I got this exception: org.apache.commons.httpclient.HttpRecoverableException: org.apache.commons.httpclient.HttpRecoverableException : Error in parsing the status line from the response: unable to find line starting with HTTP at org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase .java:1965) at org.apache.commons.httpclient.HttpMethodBase.processRequest(HttpMethodBa se.java:2659) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java :1093) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:6 75) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:5 29) I wonder if a heavy load in server site? How to fix this issue? Thank you very much, Please help. Chwang For example these following parameters I need to contains them in url. If cut them to half, it works fine. But if not, I got unable to find line starting with HTTP (tblCase.CaseTypeCode = '21' OR tblCase.CaseTypeCode = '210001' OR tblCase.CaseTypeCode = '210002' OR tblCase.CaseTypeCode = '210003' OR tblCase.CaseTypeCode = '210004' OR tblCase.CaseTypeCode = '210005' OR tblCase.CaseTypeCode = '210006' OR tblCase.CaseTypeCode = '210007' OR tblCase.CaseTypeCode = '210008' OR tblCase.CaseTypeCode = '210009' OR tblCase.CaseTypeCode = '210010' OR tblCase.CaseTypeCode = '210011' OR tblCase.CaseTypeCode = '210012' OR tblCase.CaseTypeCode = '210013' OR tblCase.CaseTypeCode = '210014' OR tblCase.CaseTypeCode = '210015' OR tblCase.CaseTypeCode = '210016' OR tblCase.CaseTypeCode = '210017' OR tblCase.CaseTypeCode = '210018' OR tblCase.CaseTypeCode = '210019' OR tblCase.CaseTypeCode = '210020' OR tblCase.CaseTypeCode = '210026' OR tblCase.CaseTypeCode = '210030' OR tblCase.CaseTypeCode = '210099' OR tblCase.CaseTypeCode = '210500' OR tblCase.CaseTypeCode = '210501' OR tblCase.CaseTypeCode = '210502' OR tblCase.CaseTypeCode = '211000' OR tblCase.CaseTypeCode = '211001' OR tblCase.CaseTypeCode = '212002' OR tblCase.CaseTypeCode = '212009' OR tblCase.CaseTypeCode = '213000' OR tblCase.CaseTypeCode = '213001' OR tblCase.CaseTypeCode = '213002' OR tblCase.CaseTypeCode = '213700' OR tblCase.CaseTypeCode = '213701' OR tblCase.CaseTypeCode = '214000' OR tblCase.CaseTypeCode = '214001' OR tblCase.CaseTypeCode = '214002' OR tblCase.CaseTypeCode = '214100' OR tblCase.CaseTypeCode = '214101' OR tblCase.CaseTypeCode = '215000' OR tblCase.CaseTypeCode = '215001' OR tblCase.CaseTypeCode = '215002' OR tblCase.CaseTypeCode = '215003' OR tblCase.CaseTypeCode = '215005' OR tblCase.CaseTypeCode = '216001' OR tblCase.CaseTypeCode = '218000' OR tblCase.CaseTypeCode = '218001' OR tblCase.CaseTypeCode = '218002' OR tblCase.CaseTypeCode = '218003' OR tblCase.CaseTypeCode = '218004' OR tblCase.CaseTypeCode = '218005' OR tblCase.CaseTypeCode = '218006' OR tblCase.CaseTypeCode = '218007' OR tblCase.CaseTypeCode = '218008' OR tblCase.CaseTypeCode = '218009' OR tblCase.CaseTypeCode = '218010' OR tblCase.CaseTypeCode = '218011' OR tblCase.CaseTypeCode = '218012' OR tblCase.CaseTypeCode = '218013' OR tblCase.CaseTypeCode = '218014' OR tblCase.CaseTypeCode = '218015' OR tblCase.CaseTypeCode = '218016' OR tblCase.CaseTypeCode = '218017' OR tblCase.CaseTypeCode = '218018' OR tblCase.CaseTypeCode = '218019' OR tblCase.CaseTypeCode = '218020' OR tblCase.CaseTypeCode = '218021' OR tblCase.CaseTypeCode = '218022' OR tblCase.CaseTypeCode = '218023' OR tblCase.CaseTypeCode = '218024' OR tblCase.CaseTypeCode = '218025' OR tblCase.CaseTypeCode = '218030' OR tblCase.CaseTypeCode = '218035' OR tblCase.CaseTypeCode = '218040' OR tblCase.CaseTypeCode = '218050' OR tblCase.CaseTypeCode = '218060' OR tblCase.CaseTypeCode = '218065' OR tblCase.CaseTypeCode = '218070' OR tblCase.CaseTypeCode = '218071' OR tblCase.CaseTypeCode = '218080' OR tblCase.CaseTypeCode = '218090' OR tblCase.CaseTypeCode = '218091' OR tblCase.CaseTypeCode = '250005' OR tblCase.CaseTypeCode = '262601' OR tblCase.CaseTypeCode = '264001' OR tblCase.CaseTypeCode = '274002' OR tblCase.CaseTypeCode = '276501') - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- [web] http://www.odi.ch/ [blog] http://www.odi.ch/weblog/ [pgp] key 0x81CF3416
Re: commons-ssl - corporate CLA sent via courier
Julius is referring to the following earlier post: http://mail-archives.apache.org/mod_mbox/jakarta-httpclient-dev/200605.mbox/[EMAIL PROTECTED] I see no problem with the BouncyCastle license. We can include the library. As discussed earlier we can put the code into a separate subproject of HttpComponents. Julius, would you be so kind to notify us when the CLA has presumably reached Apache, so we can ask confirmation from the secretary? Thanks. Odi Julius Davies wrote: Sorry to httpclient-dev about the long delay on this. I went on a 3 week vacation shortly after my original email and just got too busy after that. I have a new feature in commons-ssl since I last wrote: - Works with Java 1.3 + JSSE I also am very close to supporting standard Apache style ssleay format RSA keys, encrypted or plain PKCS-1. These are the same keys you create by following this FAQ: http://httpd.apache.org/docs/2.2/ssl/ssl_faq.html#selfcert I have some experimental code (not uploaded yet) that can handle the following types (with help from BouncyCastle's ASN parsing): #1. RSA key - not encrypted! -BEGIN RSA PRIVATE KEY- MIICXgIBAAKBgQDiLwhut8clGGkLoGq86u+IMh8HE5YSwmWgC6QqlyBXcBrlK87p [] #2. RSA key - encrypted! -BEGIN RSA PRIVATE KEY- Proc-Type: 4,ENCRYPTED DEK-Info: DES-CBC,[8-byte-binary-salt/iv] #3. DEK-Info: DES-EDE3-CBC,[8-byte-binary-salt/iv] #4. DEK-Info: AES-128-CBC,[16-byte-binary-salt/iv] #5. DEK-Info: AES-192-CBC,[16-byte-binary-salt/iv] #6. DEK-Info: AES-256-CBC,[16-byte-binary-salt/iv] I'm going to create a formal commons-ssl project proposal. But I'm also going to be really tightly coupled to HTTPClient - CRL checking is going to be mostly supported through HTTPClient! So I'm wondering if maybe it should all just be part of httpclient.jar. If I do create a commons-ssl sub-project in the incubator, I'm wondering if Oleg or Sebb or anyone else here would like to join. Oleg - I'm especially indebted to you. Your httpclient-contrib examples were very very helpful to me and CUCBC these past two years. I've been using your Auth example in production for at least 1.5 years now. yours, Julius Davies Senior Application Developer Credit Union Central of British Columbia http://juliusdavies.ca/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpClient-HttpComponents relationship
Nicolás, It says on the front page: Jakarta HttpComponents project is charged with developing and maintaining Commons HttpClient. Commons HttpClient 3 series will be maintained until Jakarta HttpClient 4 is deemed stable enough to supersede it for use in production. Feel free to submit a better sentence. Cheers Ortwin Nicolás Lichtmaier wrote: I can't find which is the relationship between these two projects. It would be nice if this can be made clear in the web pages! (That's why I'm posting this in this list). BTW, I need to asynchronously get a lot of URLs (using pipelining if posible), HTTPAsync seems the right thing to use, but everybody points at HTTPClient. What do I do? Many thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- [web] http://www.odi.ch/ [blog] http://www.odi.ch/weblog/ [pgp] key 0x81CF3416 finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NTLM supported in JRE 1.5.0_08
Roland Weber wrote: Hi Odi, Oleg, It's maybe noteworthy that the HTTP client within the brand new JRE version now supports NTLM: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4626557 I don't see what this has to do with the brand new JRE version? The bug report says fixed since 1.4.2, and we've know that the 1.4 JDK on Windows supports NTLM for a while. I don't know... I just saw it in the release notes. See for yourself: http://java.sun.com/j2se/1.5.0/ReleaseNotes.html#150_08 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
NTLM supported in JRE 1.5.0_08
It's maybe noteworthy that the HTTP client within the brand new JRE version now supports NTLM: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4626557 Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subscriptoin issue
Make sure you leave the Subject and Body of your subscription email blank. I can subscribe with no problem. I have sent a request to subscribe your address. You should get a confirmation email now. If it still does not work, you may file a problem report: https://issues.apache.org/jira/browse/INFRA Cheers Ortwin Glück Veni Garg wrote: I apologise for spamming this list, but I am trying to subscribe to the httpclient-User list and the two times I have sent a request for subscription, I get rejected with the following message-- Any ideas or suggestions? THanks much! --- [EMAIL PROTECTED]: 140.211.166.49 failed after I sent the message. Remote host said: 552 spam score (5.4) exceeded threshold --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NTLM supported in JRE 1.5.0_08
Interesting question, Oleg. I don't know to be honest. I just read the release notes and that's what caught my eye. It would be interesting to see if there is a sun.*/com.sun.* class that we could write an AuthenticationScheme wrapper for :-) Odi Oleg Kalnichevski wrote: On Fri, 2006-08-11 at 18:00 +0200, Ortwin Glück wrote: It's maybe noteworthy that the HTTP client within the brand new JRE version now supports NTLM: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4626557 Odi Odi, The details about the fix in the issue report are kind of scarce. Does this require a native platform support for NTLM or is it truly pure Java implementation? Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Unable to parse header issue
Todd, The question is not *how* to handle this in your code, but rather *if*! That system is not speaking HTTP, but something else. Why bother at all? If you can, you should speak to the operators of that system and make them comply with the (at least the basic) HTTP standard. Odi Todd Wilson wrote: I can certainly understand not wanting to deal with this. From the standpoint of an HttpClient user, the tricky part is that I can't think of a workaround if I still want to be able to work with this site. The only option I can think of would be to fork HttpClient and provide my own fix, which I really have no desire to do. I guess the question becomes, to what degree should provisions be made to deal with non-conforming web servers? HttpClient already does this to some degree in the way it works with cookies (e.g., a Compatibility setting), among other things. In this particular case, the server's response is obviously very flawed, so it may fall outside of this threshold of scenarios you're willing to deal with. Again, the trouble is that I have no way of elegantly handling this in my own code. If I want to use HttpClient I simply wouldn't be able to work with this site. Todd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: RE: MultithreadedConnectionManager pooling strategy]
Yep, seems to make sense. Odi Oleg Kalnichevski wrote: Folks, The message I am forwarding was sent to the HttpClient user list a while ago. I think the changes proposed by Balazs are very reasonable. Unfortunately Balazs never submitted the patch and did not return emails I had sent him off-list. Nonetheless, I think we should consider changing MultithreadedConnectionManager's behavior as proposed by Balazs and include those changes into 3.1-beta1 Mike, what do you think? Oleg Forwarded Message From: SZÜCS Balazs [EMAIL PROTECTED] Reply-To: HttpClient User Discussion httpclient-user@jakarta.apache.org To: 'HttpClient User Discussion' httpclient-user@jakarta.apache.org Subject: RE: MultithreadedConnectionManager pooling strategy Date: Mon, 15 May 2006 15:26:08 +0200 Hello, I made two changes to the HttpClient code: 1) in the class ConnectionPool in the method getFreeConnection( ... ) I changed freeConnections.removeFirst() to freeConnections.removeLast(). Now the container for free connections behaves as a stack rather than a queue. 2) additionally I changed the IdleConnectionTimeoutThread, in the run() method I added connectionManager.deleteClosedConnections() so that the pool size is maintained correctly. What do you think? Balazs -Original Message- From: Oleg Kalnichevski [EMAIL PROTECTED]@DSI Sent: Donnerstag, 04. Mai 2006 18:07 To: HttpClient User Discussion Subject:Re: MultithreadedConnectionManager pooling strategy On Thu, 2006-05-04 at 18:00 +0200, SZÜCS Balazs wrote: Hello, I'm using HttpClient 3.0-rc4, and I have a question about the connection pooling strategy of MultithreadedConnectionManager. The reason for that is that I use an IdleConnectionTimeoutThread (runs every 60 secs, using a timeout of 60 secs) configured with a MultithreadedConnectionManager, and idle connections don't seem to get closed by the IdleConnectionTimeoutThread. However, on a long time span (overnight) the pool size decreases, but I would expect a quicker reaction, when my application is not unter heavy load. I've taken a look at the source of MultithreadedConnectionManager, and I realized, that free connections are stored in a linked list. On demand the next free connection is taken from the BEGINNING of the list, while after usage the connection is put back to the END of the list. This seems to me a round robin behavior, and it might prevent connections reaching the predefined age for being recognized as idle. If there is some load, each free connection will be used, instead of just using a few of them, and letting the rest age. Does that make any sense? Balazs, Yes, it does. Please file a bug report in Bugzilla. Feel free to provide a patch for the problem. We love patches ;-) Oleg Thank you! Balazs - 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] -- [web] http://www.odi.ch/ [blog] http://www.odi.ch/weblog/ [pgp] key 0x81CF3416 finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sending XML files using HTTP Request/Response?
Veni, This is the developer mailing list, but your question is a typical user question. You may get more detailed information on the user list: http://jakarta.apache.org/commons/httpclient/mail-lists.html Yes, HttpClient seems like the way to go. Have a look at this sample code which is part of the example package: http://svn.apache.org/repos/asf/jakarta/commons/proper/httpclient/trunk/src/examples/PostXML.java The 10 minute scheduling is of course out of the scope of HttpClient. But it's easy to do using for example the Timer class. Cheers Ortwin Veni Garg wrote: Hey ! I am not sure if this is the right forum for this question, please redirect me if this is not. With that, here is a question ... from a novice really. We have a situation where we need to send an XML file from our server to another server..URL really (http:// abc.com/xyz.crspx). This URL expects this XML file, reads and sends us back a response (with success or error codes etc) which I need to write to a file and save. The XML file itself contains the authentication information which the remote server will use before it sends a response back. Is this something I should use HTTP Request/Response for. Can I do this in a batch mode where this program runs every 10 mts and picks up an XML file in a predetermined location and transmits it. Are there limitations to the size of the XML file. I read that HTTPClient can help me do this. Any direction on how to proceed will be very helpful. Suggestions resources are appreciated. Thanks much! V Veni Garg Sr. Programmer Analyst Data Select Systems Inc. Ph: (805) 446-2090 Fax: (805) 446-2089 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpComponents] fold HttpNIO into HttpCore
sebb wrote: Probably also need to change the JVM bootstrap jars to 1.3? Hm... You got a point there. Sounds very hackish. Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpComponents] fold HttpNIO into HttpCore
Hi Oleg, It's true that we have agreed [1] on 1.3 for HttpCore and 1.4 for NIO. So it makes sense to put the NIO code into a separate code directory. That the NIO code will be small in size, doesn't come as a surprise to me. And I absolutely agree that it doesn't make sense to put it under a separately release cycle. hack on Odi [1] http://wiki.apache.org/jakarta-httpclient/HttpClientApiRedesign?action=recallrev=30 Oleg Kalnichevski wrote: Folks, I have started working on NIO extensions to HttpCore. So far it looks like there will be fairly little code involved and there will be virtually no changes to the protocol layer of HttpCore required. This leads me to believe that HttpNIO as a separate module with an separate release cycle does not actually make any sense. My Evil(tm) Plan is to introduce an additional module to HttpCore SVN project in order to keep Java 1.4 dependent NIO extensions separate from the rest of HttpCore that requires Java 1.3 only. Maven2 fully support multi-module projects and conditional compilation based on JDK version. This way Java 1.3 could still compile a fully functional Java 1.3 version HttpCore without NIO extensions. What do you think? Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- [web] http://www.odi.ch/ [blog] http://www.odi.ch/weblog/ [pgp] key 0x81CF3416 finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpNIO] MINA and AsyncWeb
Hi Pete, peter royal wrote: (resending since i think my first try didn't get noticed by the httpclient-dev moderators) Our moderator is on vacation and moderation requests are automatically /dev/nulled for the time being. Sorry for the inconvenience. howdy! I'm writing to see if there is interest in collaborating in a larger effort to develop HTTP code that utilizes NIO. Absolutely. Roland Weber is just setting up to prepare the HttpAsync component architecture. So there couldn't be a better time for this connection! There is already a design document available: http://wiki.apache.org/jakarta-httpclient/HttpAsyncThreadingDesign MINA http://directory.apache.org/subprojects/mina/ is a framework here at the ASF for developing clients and servers based on NIO. There is also the AsyncWeb http://asyncweb.safehaus.org/ project that builds on top of MINA to create an HTTP server (not Servlet based). AsyncWeb will likely be proposed for incubation shortly, and I wanted to see if there was interest from this community on some of the common parts between a HTTP client and server implementation. MINA already has the nitty-gritty details of NIO worked out, so its just a matter of building protocols on top of it. MINA's architecture then makes it possible to share code on both the client and server sides. (MINA has the notion of a filter-chain that processes data read from the socket, and thus common protocol-level items can be implemented as a filter and then re-used on both a client and server). This sounds all very promising. If done right it could keep HttpAsync to a minimum if not elimiate it completely. I know that the HttpClient project has done extensive work on fully supporting the HTTP protocol, so pairing that expertise with an existing IO layer would be beneficial for all, I hope. (thus freeing this project from having to maintain the lower IO layer, and allowing concentration on protocol-level details). This would also mesh well with the HttpComponents charter, since it would provide an implementation of a full server that would (hopefully!) utilize your NIO-based components. I've cc'ed [EMAIL PROTECTED], as its a common spot for people that have this shared interest to discuss. thanks! Please pair up directly with Roland to coordinate your efforts. -pete Thanks for the pointer! Happy hacking Ortwin -- [web] http://www.odi.ch/ [blog] http://www.odi.ch/weblog/ [pgp] key 0x81CF3416 finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Force-close connections queston
Jeremy Hicks wrote: I get a NullPointerException on this line: ((SSLSocket)MyConnectionHelper.getSocket(conn)).getSession().invalidate(); Can anybody tell why? Maybe, because one of those reference is null? I am sure you can figure out which one. Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Greg Watson/IS/SLC/StandardLifeGroup is out of the office.
Hi, Your out-of-office bounces annoy people on mailing lists you are subscribed to. Please do not use this feature. Cheers Orwin Glück [EMAIL PROTECTED] wrote: I will be out of the office starting 14/07/2006 and will not return until 18/07/2006. If urgent, please contact [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 running a JavaScript Function
Gerdes, Tom wrote: Which WebServices API would allow me to access a client or vendor's web page and automatically upload or download data without human intervention. In the same way that I can through Htppclient? That was just an architecture side kick. You should talk to your vendor or client to provide such a service. WebServices are HTTP + XML interfaces designed for machines. Webpages are HTTP + HTML GUI interfaces designed for humans. What you are doing is like automating MS Word by emulating mouse clicks to the GUI, instead of scripting Word with VBA! Ortwin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Httpclient running a JavaScript Function
Tom, HttpClient is not a browser. It is content agnostic actually. If you are looking for a JavaScript engine you may want to check out Rhino. However, I recommend you don't try to emulate a web browser and use a WebServices API rather than an interface designed for humans. Cheers Ortwin Gerdes, Tom wrote: I am using Jakarta-Commons Httpclient 3.0 to access a web page and automate sending data from my database to a web site. Upon connecting to the web site I receive a Javascript file as part of the response to my GET method. Does Httpclient have a way to execute a function in the Javascript file. I am trying to emulate the IE browser, and it has the capability to run a Javascript function. If this is not a capability of Httpclient 3.0, is there another java package that you can recommend? -- [web] http://www.odi.ch/ [blog] http://www.odi.ch/weblog/ [pgp] key 0x81CF3416 finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Force-close connections queston
Jeremy Hicks wrote: We are using the EasySSLProtocolSocketFactory written by Oleg which is under com.sun.net.ssl.*. Huh, what is under com.sun? I wasn't able to see a method for SSLContext called getClientSessionContext(). http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/SSLContext.html#getClientSessionContext() If there is a known way to invalidate the session using this class, that would be great. With this class we are getting, what appears to be, one full handshake that is being shared across all threads that are running instead of getting one full handshake for each thread (which is what a browser does). Yes, that's true. This implementation is not perfect. It's a basis. We happily accept patches, however. However, since I couldn't find that method, instead I tried a modified version of the EasySSLProtocolSocketFactory class which uses the javax.net.ssl.* classes. I fail to understand... Using that, it seems that ALL SSL handshakes are full and that none of them are abbreviated. Maybe you are not keeping any SSL sessions? It didn't seem to matter what I set the session cache size or session timeout to, I always got the same results. (I was trying to set these within the getEasySSLSocketFactory() method.) It also didn't seem to matter if I used the MultiThreadedHttpClientManger or my own that force-closes the HTTP connections. Where should I be making the call to SSLSocket.getSession() to try and invalidate the session there? I think the best place to invalidate the session is from a custom connection manager in its releaseConnection method like so: ((SSLSocket) conn.getSocket()).getSession().invalidate(); Am I missing something basic here? If I'm not being clear enough, please let me know. Hope that helps Ortwin Glück Jeremy Hicks Novell, Inc., the leading provider of information solutions http://www.novell.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Force-close connections queston
Jeremy Hicks wrote: EasySSLProtocolSocketFactory written by Oleg uses the SSL libraries which are under com.sun.net.ssl as opposed to the ones you suggested which are under javax.net.ssl. Ah, now I understand. That was changed in February: http://issues.apache.org/jira/browse/HTTPCLIENT-559 There is no getClientSessionContext() method when using the SSL libraries from com.sun.net.ssl. It is only under javax.net.ssl. Of course. I'll try this out. Thanks again for your help. Prego Ortwin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: connecting to htttps site failed if certificate is expired
Hi, This is an issue of your JSSE implementation (the one by Sun) and not HttpClient. Thus we can only offer limited support. I guess you need to implement a suitable TrustManager that allows for this case. You may want to have a look at the contrib code: http://svn.apache.org/repos/asf/jakarta/commons/proper/httpclient/trunk/src/contrib/org/apache/commons/httpclient/contrib/ssl/ Maybe there is also a config option to achieve this. I don't know. Cheers Ortwin Dhanasekaran Vivekanandhan wrote: Hi All, I am using HttpClient and GetMethod classes to connect to a https site,but the certificate provided by the site is expired.so I am getting the following exception.Is there a way to connect to https site even if the certificate provided by the site is expired Exception: - : sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target __ 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SO_TIMEOUT Question
Saminda Abeyruwan wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Devs, Is the following code, httpClient.getHttpConnectionManager().getParams().setSoTimeout(soTimeout); is same as httpclient.getParams().setParameter(http.socket.timeout, new Integer(soTimeout)); Yes. If so, 1. Do i have to do setHttpConnectionManager() before doing getHttpConnectionManager() to the httpclient object. No. HttpClient will the default connection manager for you if not overriden in the constructor. See http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/httpclient/params/HttpClientParams.html#CONNECTION_MANAGER_CLASS 2. If i put 0 as the input, does the so_timeout set for infinity. Yes. See http://java.sun.com/j2se/1.4.2/docs/api/java/net/Socket.html#setSoTimeout(int) Thank you Saminda YAW Ortwin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Force-close connections queston
Jeremy Hicks wrote: We have written a client that logs into a web application and then gets redirected to a web resource. We want to use SSL during this process. Everything seems to be working fine, but we noticed that abbreviated handshakes are being done instead of a full handshake. Jeremy, Here is my understanding of the situation: ___ SSL session != HTTP session SSL is a stateful protocol. That's why there is the term SSL session. As SSL is not something specific to HTML this session has nothing to do with HTTP session state (cookies, etc.). More specificly this session is not tied to a single connection. Like a HTTP session it usually spans multiple connections between the same endpoints. ___ SSL session stores keys SSL establishes a key pair with the host during a full handshake. This key pair is expensive (asymmetric encryption is slow) to generate. It is used to transfer a symmetric key (symmetric encryption is fast). This symmetric key and the asymmatric pair is subsequently cached in the SSL session. Typicall the key will expire after 24 hours and a new one will be generated. The abbreviated handshake uses this cached information to resume the session in a secure way with less computational overhead (by simply reusing the symmetric key). Java SSL implementations JSSE is the Java standard for SSL implementations. Its interfaces are in javax.net.ssl. There you find the class SSLSession: http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/SSLSession.html SSL implementations have to implement this interface. The interface provides an invalidate() method. Access to the SSLSession object is possible through: * SSLSocket.getSession() * SSLContext.getInstance(...).getClientSessionContext().getSession(...) The client SSLSessionContext http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/SSLSessionContext.html also has methods to control the session cache size and the session timeout. This may be useful in your situation. Hope that helps. Ortwin Glück - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 22940] - gzip content-encoding support
When will Bugzilla be set to read-only mode? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons HttpClient 3.1-alpha1
+1 forza Italia Odi Oleg Kalnichevski wrote: I propose that we mark the latest code in the SVN trunk as 3.1-alpha1 and proceed with a release. Please vote as follows: -- Vote: HttpClient 3.1-alpha1 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] -- [web] http://www.odi.ch/ [blog] http://www.odi.ch/weblog/ [pgp] key 0x81CF3416 finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpClient 3.1-alpha1 release? Any interest?
Oleg Kalnichevski wrote: Folks, We are just three issues away from the 3.1 alpha1 milestone http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=12310360fixfor=12311100 Two out of three HTTPCLIENT-588 and HTTPCLIENT-587 have patches and just need to be formally approved by another committer. Odi, are you planning to do anything about HTTPCLIENT-547? Essentially it is the only thing that really blocks the release. Anyways, is there any interest in cutting 3.1a1 or everyone is just too busy watching football? Shall we wait until the end of the world cup? Hmm... It's too hot too think at the moment. I can take care of it when the Zurich weather gets cooler. It wasn't even that hot in Naples (worth a visit btw)! I only care about soccer when the Swiss are playing :-) Find me at the lake Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpAsync Design - please review
Roland, Overall it looks very good. I only find the red/cyan diagrams a bit cumbersome. A UML interaction diagram would be clearer for me to read. Odi Roland Weber wrote: Hi all, I have completed a first version of the wiki page on the HttpAsync design: http://wiki.apache.org/jakarta-httpclient/HttpAsyncThreadingDesign I will later add details about the use of background threads in dispatcher implementations, but I want to gather some feedback on the design level first. In particular, I'm interested in your opinion on the red vs. cyan design question. The current implementation is based on the red design. Note: as all communication on this mailing list, this request for review is addressed to _everyone_, not just to the usual suspects. If you have a view, please share it with us. Rationales are welcome, but not required. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- [web] http://www.odi.ch/ [blog] http://www.odi.ch/weblog/ [pgp] key 0x81CF3416 finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpClientApiRedesign in Wiki
Oleg Kalnichevski wrote: Are there any objections to removing the proposal document? No. Go ahead. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpCore] Axis2 SimpleHttpServer powered by HttpCore
It's good to have a real application. So of course +1. Odi Oleg Kalnichevski wrote: Folks, As you may know presently Axis2 uses a fork of our testing HTTP framework as a basis for their implementation of a simple HTTP server. Obviously, those classes were never meant to be used for anything remotely serious beyond allowing us to run unit tests against a 'live' HTTP service and are quite wacky. I have submitted a patch to replace the actual SimpleHttpServer implementation with a new one based on HttpCore http://issues.apache.org/jira/browse/AXIS2-761 It actually looks like the patch is going to be accepted. Axis folks requested a new release of HttpCore incorporating all the latest fixes from SVN trunk, which they could depend on. This is quite reasonable. Do you see any problem if we cut ALPHA-2 ahead of the schedule, sometime in the coming days? There have been almost no new features and API changes worth mentioning, so ALPHA-2 is going to be a bug fix release. I just want a fix for HTTPCORE-4 to go in the new release and will hack up a patch today or tomorrow. What do you think? Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- [web] http://www.odi.ch/ [blog] http://www.odi.ch/weblog/ [pgp] key 0x81CF3416 finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpAsync Design - please review
Roland Weber wrote: Maybe somebody else on this list wants to jump in and create some UML diagrams with the appropriate tools? They are so simple, I usually do them in PowerPoint :-) Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [an error occurred while processing this directive]
Or just use a sniffer like Ethereal. Ortwin sebb wrote: You need to find out what IE is sending to the server - for this you can use a proxy such as Apache TCPMon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [an error occurred while processing this directive]
Muli, To help you more information is necessary. Please send the relevant section from the log and the stacktrace. See http://jakarta.apache.org/commons/httpclient/logging.html Cheers Ortwin Muli Assa wrote: I try to load URL and get the above error message I found that the same message is generated by Netscape 7.2 but not in IE 6.0 Can I instruct HttpClient to support the IE 6.0 functionality? Thanks, Muli Assa office: 650.603.5217 mobile: 650.450.0978 -- [web] http://www.odi.ch/ [blog] http://www.odi.ch/weblog/ [pgp] key 0x81CF3416 finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Resolved: (HTTPCORE-3) HttpParser triggers unfriendly OutOfMemoryError on challenging input
Gordon Mohr wrote: If I understand the HttpCore code properly, there is no direct facility for protecting against the OOME in the code -- just a chance to hook in a theoretical alternate implementation that would address the problem. Is that correct? Yes. To use the HttpCore-4.0 facility, it appears I would create my own HttpDataReceiver implementation which keeps a count of the bytes it shovels throws an IO or HTTP exception when some count is exceeded; create a factory that makes such receivers; install that factory into each HttpClientConnection instance before it begins receiving data. Correct. This could work, but seems a roundabout and obscure approach. The really valuable feature would be for OOME-resistance -- and friendly, usable indicators that extreme content has been encountered -- to be features of the library. It's require a switch or paramter to enable, rather than patching in custom/third-party code. An OOM Exception is exactly that: a friendly usable indicator that an extreme condition has been encountered. I am personally against another mechanism that tries to somehow monitor heap memory. I agree that by sending large header information a malicious server could DOS a spider based on HttpCore. So it makes sense for this use case to include a protection parameter that sets an upper limit to the information in headers. A default of 100 KB should be enough for the real world. This is the easy solution. Another possibility is to use a header stream like we do for the message body. This would mean a refactoring and probably cause painful client code. We would still have to protect ourselves against long header lines which is again not easy. This all boils down to a missing feature: byte counting in the connection. Is there a summary of expected dates of Core-4.0/Client-4.0 release somewhere, or any assessments of how the 4.0 codebases match up against 3.0 features? (Is it reasonable for an HttpClient-3.0-using project to consider transitioning to the 4.0 codebase(s)?) This is the only plan there is: http://wiki.apache.org/jakarta-httpclient/HttpComponentsProjectRoadmap - Gordon @ IA Ortwin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NTLMv2 implemetation is ready
Hi Konstantin, This sounds interesting. It would be nice to have a look at your code. Can you put it on a server somewhere? Here is some strategic information: We would like to completely factor out NTLM (1 and 2) of HttpClient code. It is complex and can not be maintained sufficiently enough by the current community. We have had a look at JCIFS and it looks like we could use that library. But currently there are still legal issues with bundling LGPL code with ASF licensed projects. That's why we have not made efforts so far. These issues are however to be alleviated in the near future: http://www.mail-archive.com/commons-dev%40jakarta.apache.org/msg79380.html Our only option for the moment is to open a SourceForge project to develop the LGPL code that links the JCIFS library to the HttpClient API. Ortwin Kasatkin Konstantin wrote: Hello guys, recently I've encouner the problem how to interact with HTTP resourses protected tough security policy allowed to use only NTLMv2 authorization scheme from a java application. Earlier I used httpclient to accomplish NTLMv1 authorization, but when I was requested to move to NTLMv2 I was surprised, that httpclient does not support this. I've dug all the Internet and found some articles and examples how to implement it, and finally having compiled all this enormous heap of information, I have a couple modified classes from httpclient project, that I'd like to share with you and other users of httpclient. Also I have written a HTTPHandler, that I use with Axis to provide the ability to connect to WebServices through NTLM. Please give me the details how to share my knowledge. Maybe it is possible to join me to your team? -- [web] http://www.odi.ch/ [blog] http://www.odi.ch/weblog/ [pgp] key 0x81CF3416 finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status page update [Was Re: svn commit: r406747]
Just do it (tm). I will see if I can make the final tweaks with the logo. Odi Oleg Kalnichevski wrote: Folks, I tool the liberty of updating the status page of the HttpComponents web site with the latest development news on each actively developed module / branch. Could you please review the changes and let me know if they are okay with you? Feel free to add more stuff, I you think something is missing. If I hear no complaints by Wednesday (May 17th), 12:00 GMT I'll go ahead and redeploy the site. Cheers, Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Jira announcement
looks good Oleg Kalnichevski wrote: Folks, I would like apply this patch to the HttpClient web site as soon as Henri makes HttpClient in Bugzilla read-only and SVN becomes read-write accessible again. Please let me know if you spot any problems with the patch. Cheers, Oleg Index: xdocs/news.xml === --- xdocs/news.xml (revision 400285) +++ xdocs/news.xml (working copy) @@ -10,6 +10,22 @@ /properties body +section name=12 May 2006 - HttpClient issue tracking migrated to Jira +p + HttpClient issue tracking has migrated from Bugzilla to Jira. Please do not enter new bug reports + and update exiting ones in Bugzilla. HttpComponents project will be using + a href=http://issues.apache.org/jira/;Jira/a to manage HttpClient related issues as of today. + Please use a href=http://issues.apache.org/jira/browse/HTTPCLIENT;this project/a in Jira to + report new issues against HttpClient and search for reported ones. All existing issue reports can + be accessed in Jira by their original Bugzilla bug id. +/p +/section +section name=08 May 2006 - HttpClient 3.0.1 released +p + HttpClient 3.0.1 has been released. This version fixes a number of bugs found since the release of 3.0. + All HttpClient users are encouraged to upgrade. +/p +/section section name=27 February 2006 - HttpClient 2.x codebase declared 'End of Life' p HttpClient 2.x will no longer be supported. There will be no more HttpClient 2.x releases Index: project.xml === --- project.xml (revision 400285) +++ project.xml (working copy) @@ -24,7 +24,7 @@ logo/images/httpclient_logo.png/logo urlhttp://jakarta.apache.org/commons/httpclient//url - issueTrackingUrl![CDATA[http://issues.apache.org/bugzilla/buglist.cgi?query_format=advancedshort_desc_type=allwordssubstrshort_desc=product=HttpClientcomponent=Commons+HttpClientlong_desc_type=allwordssubstrlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=keywords_type=anywordskeywords=bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=NEEDINFOemailassigned_to1=1emailtype1=substringemail1=emailreporter2=1emailtype2=substringemail2=bugidtype=includebug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0=nooptype0-0-0=noopvalue0-0-0=]]/issueTrackingUrl + issueTrackingUrlhttp://issues.apache.org/jira/browse/HTTPCLIENT/issueTrackingUrl siteAddresspeople.apache.org/siteAddress siteDirectory/www/jakarta.apache.org/commons/httpclient//siteDirectory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- [web] http://www.odi.ch/ [blog] http://www.odi.ch/weblog/ [pgp] key 0x81CF3416 finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migration to Jira
Henri Yandell wrote: Will work on this. How does the following sound: Migrate HttpClient from Bugz to Jira Move the issue in HTTPCore into the HttpClient project Delete HttpCore Rename HttpClient to HttpCore Oops no! HttpClient is very different from HttpCore. We want both projects separately. If so, I think I can go ahead and do it asap. No need to tie with Commons at all. Hen Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Tutorial in Wiki
Roland, It's very good! But I find it a bit focussed on a bad practice solution often endorsed by hobbyists. Programmatic processing of HTML pages is really not something you should do. HTML interfaces are for humans not for computers. This should be pointed out. I would like to see a more professional use case that uses an XML interface for instance. Or one that downloads a document from a document management system. Unfortunately I have very limited time currently... Odi Roland Weber wrote: Hi all, I have collected some of the information available in the mailing list archives into a new Wiki page: http://wiki.apache.org/jakarta-httpclient/ForAbsoluteBeginners The new page does not explain how to use the HttpClient API, but what to use it for. This was inspired earlier this year, mainly by Jerry and Rajapandian. I feel that this kind of tutorial has been missing so far, if not from the internet then at least from the higher ranks of Google and Altavista search results. Please review, correct, and suggest improvements. Once the first round of reviews is completed, we can consider adding a link to the user guide and/or tutorial on the HttpClient site. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- [web] http://www.odi.ch/ [blog] http://www.odi.ch/weblog/ [pgp] key 0x81CF3416 finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpComponents] Jira project for HttpCore
Awsome! I will have a look as soon as my JIRA account is reactivated with a valid email address by the admins. Odi Oleg Kalnichevski wrote: Mike, Odi, Roland, et al We have got a shiny new Jira project for HttpCore. Hurray! http://issues.apache.org/jira/browse/JHCHTTPCORE I took the first stab at configuring the project and set up the notification and permission scheme for the project. I assigned your accounts the the project developer group, which also gives you Jira admin rights. However, I believe your accounts are no longer up to date (at least email address) Please review the settings and make adjustments you deem necessary. I will be manually migrating HttpCore related open issues in the coming days, so expect some Bugzilla and Jira spam Cheers, Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logo proposal
Oleg Kalnichevski wrote: It appears we all agree to disagree. Tastes differ, don't they? How about that? We simply keep them all! We can put red one on the HttpCore site, green one on the HttpAsync site, light blue on the HttpComponents project site, and so on Oleg I have to oppose this unfortunately. The logo variants are meant as alternatives. They do not form a color palette to be used simultanously because the colors were not designed to match together. They work each indivually but not as a group. Either we decide on a single color or then a (sufficiently sized) color palette must be designed for this purpose. Anyway, everybody seems pleased with the actual design (not only the color). So I suggest we simply raise a public vote. Ortwin -- [web] http://www.odi.ch/ [blog] http://www.odi.ch/weblog/ [pgp] key 0x81CF3416 finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] HttpComponents Logo
This is a formal vote on the future HttpComponents website logo. The vote is equally open to all members of the HttpComponents community. There is no veto. The vote ends three days from now: 2006-04-23 11h30 GMT. [ ] I favour the BLUE logo http://people.apache.org/~oglueck/blue.png [ ] I favour the LIGHT BLUE logo http://people.apache.org/~oglueck/lblue.png [ ] I favour the RED logo http://people.apache.org/~oglueck/red.png [ ] I favour the GREEN logo http://people.apache.org/~oglueck/green.png [ ] I would like a new COLOR PALETTE so each product can have its own logo color. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logo proposal
Feedback from non-committers is very much appreciated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Logo proposal
Dear fellows, I have uploaded four variants of the proposed logo for your consideration. Please post your opinion and comments to this list. All artwork was created by Regula Wernli. http://people.apache.org/~oglueck/blue.png http://people.apache.org/~oglueck/lblue.png http://people.apache.org/~oglueck/red.png http://people.apache.org/~oglueck/green.png Ortwin Glück - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpComponents] Cutting the very first release: Maven release plugin trouble
Oleg Kalnichevski wrote: Essentially, we have two options here (1) keep things as they are at the moment thus probably having to manage the release process manually (2) restructure the repository in order to make Maven2 happy. Since we have not had a single official release to this point now would be the least disruptive moment to go ahead with such restructuring Opinions? Oleg Even if it's a bit of work I suggest changing the SVN structure. It is a clean approach how Maven expects the structure. Our current one doesn't reflect things appropriately. Odi -- [web] http://www.odi.ch/ [blog] http://www.odi.ch/weblog/ [pgp] key 0x81CF3416 finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpCore] Header should implement equals and hashCode
Oleg Kalnichevski wrote: How do you see the identity equality of HTTP headers? (1) By header name These headers are identity equal Content-Type: text/plain Content-Type: text/xml But these are not Content-Type: text/plain Content-Length: 0 (2) By header and case-insensitive value These headers are identity equal Content-Type: text/plain Content-Type: text/plain Content-Type: TEXT/PLAIN But these are not Content-Type: text/plain Content-Type: text/xml Content-Type: text/xml; charset=utf-8 Content-Type: text/xml; charset = utf-8 Anyway I look at it it just does not seem right. The only reasonable case I see is that an HTTP header is identity equal to itself (this), which I believe is the case with the current implementation Oleg I see the problem, Oleg. My suggestion would have been case-sensitive name + value. I was just thinking of any sort of serialization which destroys object identity. Maybe it's just because I currently work on a lot of J2EE code where Serialization and different classloaders are always an issue... Odi -- [web] http://www.odi.ch/ [blog] http://www.odi.ch/weblog/ [pgp] key 0x81CF3416 finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r391135 - in /jakarta/httpcomponents/trunk/http-core/src/java/org/apache/http: ./ impl/
Roland Weber wrote: Hi Odi, first let me thank you for the work you put into documenting the interfaces. Good job! Now for the details... The format for inline JavaDoc links is [EMAIL PROTECTED] target text}. The text is optional (I've had problems with earlier versions of JavaDoc auto-inserting argument lists with full package names), but the curly braces are required for the JavaDoc tool to detect the inline link. http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/[EMAIL PROTECTED] Thanks for pointing it out. I use braces normally but this time somehow didn't and Eclipse didn't complain. Sorry for breaking the tool - I didn't actually run it. Which - once again - shows that all code is broken as long as it is untested. /** * pAn HTTP header./p I know this wasn't inserted by you, I just happened to see it in the commit mail. The p.../p tags here are pointless. They don't seem to cause any harm (here), but the algorithm that picks the first sentence for the summary pages is supposed to stop after the first point followed by a whitespace, and /p is not a white space. We should remove such tags if we happen to come across them. http://java.sun.com/j2se/javadoc/writingdoccomments/index.html#descriptions Note to self: the writingdoccomments site recommends writing Gets the label. rather than Get the label. I'm sure I've read the opposite recommendation somewhere sometime, and have tried to stick to that for http-async. I'll change back to the (actually) recommended style, which is what I'm used to anyway :-) I like the third person form too. cheers, Roland -- [web] http://www.odi.ch/ [blog] http://www.odi.ch/weblog/ [pgp] key 0x81CF3416 finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[HttpCore] Header should implement equals and hashCode
Oleg, I think the Header class should implement equals and hashCode. Header is used in HeaderGroup in a List. The remove method of is used which uses equals to identify the right object. Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpComponents][HttpCore] ALPHA-1?
Oleg, I have now reviewed the HttpCore code base. I have not found any design flaws. The interface looks very much to my liking. You have done a very good job! Cheers Odi Oleg Kalnichevski wrote: If my memory serves me well all suggestions and concerned expressed by Odi and Roland during the first round of internal reviews have been addressed. I believe at this point [HttpCore] is in a good shape for the first ALPHA release. Some external feedback on the new API would be quite beneficial. Are there any objections to calling a formal vote on HttpCore 4.0-alpha1 release? Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hi ... httpclient for PDF files ???
Vijay, Sorry we can not help you without any logging output. A quick guess is, that the server may use gzip/deflate compression, which is not handeled automatically by HttpClient. You may have to run the stream through GZIPInputStream or InflaterInputStream depending on the HTTP headers. Cheers Ortwin Glück Vijay Gomatam wrote: Ortwin ... Thanks for the reply. I tried a lot on it, but was unsuccessful. So, I shall go ahead and use the traditional openConnection() . Anyways! Attached is the error (as image file) fyi. Thanks for your time. Regards, Vijay. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FormsLoginDemo
John, This is how the server behaves. It redirects you to the same login form. There is nothing wrong with that. Ortwin Glück Wagner, John (MED US) wrote: Redirect target: https://softwarereg.sun.com/registration/developer/en_US/authenticate Redirect: HTTP/1.1 200 OK Why does it do the redirect even though I didn't enter valid information? Thanks, Jack - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpComponents] Migration to Jira (once again)
Oleg Kalnichevski wrote: Taking all this into account I believe we might be better off at this point setting up a brand new Jira projects for [HttpCore], [HttpNIO] and [HttpAsync], getting some first hand experience with Jira, and considering migrating HttpClient from Bugzilla at some point in the future provided we are reasonably satisfied with Jira. I will manually migrate [HttpCore] related issue reports from Bugzilla to Jira. There are probably no more than 5 or 6 of those in total What do you think? Oops that's true. I think your proposal is the way to go, Oleg. Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NTLM proxy auth
John, We currently have no plans to change the NTLM support in HttpClient. We would like to hand off NTLM support completely to a third-party library as the code is complex and the protocol is undocumented. So it's necessary that it be maintained by someone doing nothing else. We would like to use JCIFS but unfortunately licensing issues prevent us from doing that. The only option I see is to make a LGPL authentication scheme that uses JCIFS and host this over at sf.net or savanna. But it's impossible for us to include it in HttpClient. Ortwin Glück Wagner, John (MED US) wrote: Oleg, Thanks for the info on NTLM. It turns out that the proxy administrators have been switching between NTLMv1 and NTLMv2 and have settled on NTLMv2. What are the plans for HttpClient supporting NTLMv2? Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: http-async: next steps
Roland Weber wrote: 5. Implement test cases based on 4 and debug the code that we have. (Includes extending the JavaDocs based on 4.) Some profiling would be good, too, to spot obvious performance loss. BTW: Check out Eclipse TPTP. It has a fantastic profiler that can even be used remotely. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bugzilla vs Jira revisited
Either make the move now or never. Although I am very happy with
Bugzilla, I can do with JIRA as well. I quite like JIRA's roadmap
feature. See
http://jira.jboss.com/jira/browse/EJBTHREE?report=com.atlassian.jira.plugin.system.project:roadmap-panel
for example. But on the other hand JIRA has some problems with deep
linking as it keeps a user session. And JIRA may not be as intuitive to
use ('find issues' is strangely designed), but looks nicer. Also
Bugzilla's mail blabber is much cleaner than JIRA's.
my 0.02 CHF
Odi
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: java.net.URL or URI
Roland Weber wrote: The URI class was introduced with JDK 1.4. HttpClient requires only an older JDK, I don't have in mind whether that was 1.2 or 1.3. 1.2 and we still have no statement about this on our website :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpComponents] web site (update 5)
Bindul Bhowmik wrote: Few very very minor cosmetic issues: Most Jakarta projects' web site headers have both the Jakarta Logo and the Project logo. But the HttpComponents website just has the Jakarta Logo. Don't dispair. The designer is working on the logo. I hope to post it for review next week. Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpComponents] web site (update 6)
I think references to HttpClient 3 should be linked to the current website. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpComponents] web site (update 4)
I am missing a Download link :-) Oleg Kalnichevski wrote: Folks, I just updated and redeployed the preview of the HttpComponents web site. Changelog: * Link to the project Wiki per Roland's request * HttpCore module now includes javadoc, source cross-reference and clover (test coverage) reports The preview can be found at the usual location http://people.apache.org/~olegk/httpcomponents/ Please let me know if you think something major is still missing. Otherwise, provided I hear no complaints I would like to go ahead and deploy the site to the official Jakarta repository Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- [web] http://www.odi.ch/ [blog] http://www.odi.ch/weblog/ [pgp] key 0x81CF3416 finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Logging Problem
Dion Gillard wrote: I'm with you. Keep the commons-logging dependency. Thanks. You know, sometimes I wish the stock JDK classes would make use of logging. Especially those that do networking, so you could figure out why something just doesn't work. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Logging Problem
Guys, I really don't see the problem with the commons-logging dependency. Dependencies to other libraries are a completely normal thing in modern software engineering. And commons logging is not an exotic one but very common. I simply don't want to make complicated workarounds to eliminate the dependency. Neither do I want to live without logging. Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpComponents] web site (update 2)
Oleg Kalnichevski wrote: What is the web server supposed to do with the following request GET .. HTTP/1.1 ? As Roland has pointed out already, such a request will never be sent to a server. Relative links in websites are absolutely normal. I mean if you build the site locally then you expect it to work, right? Not if one uses Maven ;-) All sub-modules are deployed in their respective home directories under 'target/site', which renders all cross-module links nonfunctional until the whole thing is deployed to its target repository. If you know how to fix that, I'll be happy to learn Oleg Okay, that's a pitty. But well... Unfortunately I have not had (not taken) the time to look into Maven 2 at all. Also I have never used multiproject features in Maven 1. I fear I am of little help here. Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpComponents] web site (update 2)
Oleg Kalnichevski wrote: On Fri, 2006-03-03 at 14:40 +0100, Ortwin Glück wrote: only a quick one: * The lessons learned page has no navigation. So the user loses track. What kind of navigation would you suggest? I'd keep it flat and just give it its own entry below Project goals. * Home in the modules doesn't work The link points to http://jakarta.apache.org/httpcomponents/. Once the site is deployed to its proper location, the link will work as intended. If you know how to bend Maven2 to dynamically generate those links based on the URL of the distribution site, I would be happy to learn what about .. ? Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpComponents] web site (update 2)
Oleg Kalnichevski wrote: On Fri, 2006-03-03 at 14:59 +0100, Ortwin Glück wrote: Oleg Kalnichevski wrote: On Fri, 2006-03-03 at 14:40 +0100, Ortwin Glück wrote: only a quick one: * The lessons learned page has no navigation. So the user loses track. What kind of navigation would you suggest? I'd keep it flat and just give it its own entry below Project goals. * Home in the modules doesn't work The link points to http://jakarta.apache.org/httpcomponents/. Once the site is deployed to its proper location, the link will work as intended. If you know how to bend Maven2 to dynamically generate those links based on the URL of the distribution site, I would be happy to learn what about .. ? Aren't relative URLs a big no-no? Who says that? The Maven specs? I mean if you build the site locally then you expect it to work, right? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: projects.apache.org]
I think we should list both: HttpClient and HttpComponents. We need maintainers of the DOAP entry: http://projects.apache.org/create.html Odi Original Message Subject: projects.apache.org Date: Tue, 28 Feb 2006 00:04:28 + From: david reid [EMAIL PROTECTED] Reply-To: Jakarta Project Management Committee List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Some of you may have visited http://projects.apache.org/, but many of you won't have. It's a new site that is intended to act as a white pages for the Apache Software Foundation. The data used to produce the site is controlled by you, the projects! Each project that is listed on the site has produced a DOAP file, either just by writing it from scratch or using the DOAP file generator that can be found on the site. Once the file has been produced it's up to you, the project, to keep it up to date. Please note there is no requirement for a project to have or maintain a DOAP file at present, but we would urge all projects to do so as this will provide the widest possible picture of the ASF and it's projects. Every time the site is generated (every 3 hours at present) the latest copies of all the DOAP files are collected, so there is no need to advise anyone when you make a change to the file. Of course you somehow need to get the file listed for the site. This is done by either adding your files location to the file https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/files.xml or by sending an email to [EMAIL PROTECTED] with the link and someone there will add it for you. If you have questions, comments or feedback please send them to [EMAIL PROTECTED] and we'll try to answer them. The site is approacing the end of it's development phase and we hope to push it more into the public eye shortly. When exactly? We don't have a date but it would be good if we had more projects represented before it went live. david -- [web] http://www.odi.ch/ [blog] http://www.odi.ch/weblog/ [pgp] key 0x81CF3416 finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cannot load rss xml with httpclient 3.0 .
Why are you using a POST method? Have you tried using a GET method?
RZG wrote:
Hi! everybody,
when i attempted load a rss url using PostMethod in httpclient 3.0,an 403
status returned.
but i can access this rss url through the ie or other browsers.
would there be any parameters must be setted?
*my code as follow:*
MultiThreadedHttpConnectionManager connectionManager = new
MultiThreadedHttpConnectionManager();
HttpClient httpClient = new HttpClient(connectionManager);
GetMethod postMethod = new GetMethod(
http://groups.google.com/group/PowereEngin/feed/rss_v2_0_msgs.xml?num=50;);
int httpStatus = httpClient.executeMethod (postMethod);
char abyte1[] = new char[10240];
System.out.println(httpStatus);
try {
Reader reader = new InputStreamReader(postMethod
.getResponseBodyAsStream());
int readlen = reader.read (abyte1);
char b[] = new char[readlen];
System.arraycopy(abyte1, 0, b, 0, readlen);
System.out.println(b);
} catch (Exception ex) {
ex.printStackTrace();
} finally {
postMethod.releaseConnection ();
}
--
[web] http://www.odi.ch/
[blog] http://www.odi.ch/weblog/
[pgp] key 0x81CF3416
finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCEMENT][HttpClient] HttpClient 2.x end of life
The HttpClient 2.x codebase is hereby declared end of life. This means: * The HttpClient 2 code base is officially unmaintained (dormant) * There will be no more HttpClient 2.x releases * The HttpClient 2.0 site will be taken offline as soon as the HttpCompontents site is set up. Community support is of course still available through the mailing lists. We strongly recommend all our users to move to the current stable version 3.0: http://jakarta.apache.org/commons/httpclient/ See http://vmgump.apache.org/gump/public/commons-httpclient-20-branch/commons-httpclient-2.0-branch/details.html for a list of dependent projects. The project team is now focussing on development of the codebase for HttpComponents which will eventually produce HttpClient 4. - Ortwin Glück - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpComponents] web site
I'll get the logo thing started with Regula. Odi Oleg Kalnichevski wrote: Folks, I started putting together a web site for Jakarta HttpComponents - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cookie processing
Jan, You should speak to the Slide people really. Chances are that you are using a cookie policy that isn't compatible with an Exchange server. Please see http://jakarta.apache.org/commons/httpclient/2.0/cookies.html for the available policies. Supply a custome one if none of the provided ones solves your problem. Modifying HttpState is not the way to go, thus ignoring your patch. Kind regards Ortwin Glück Hoef, Jan wrote: Hi, I am working with the jakarta project slide that uses the commons-httpclient-2.0.2. I have written a client that sends requests via webdav to the microsoft exchange server 2003. In the exchange server form based authentication is active. Wenn I enter my logon credentials in my post request, the server responds containing 2 cookies that are needed in all next request. These cookies are, e.g.: - sessionid=4241de88-1c21-4f39-b7b7-f50a87d6a828, 0x409; path=/ - cadata=1,kou8Vc9O9nrV4YRnTwVz6QMNbuiWuIg2NprLOkMT4NEcDtGkSTB2P9ORB2QUHsu P+E2OfwYC4rWCMgGe; HttpOnly; secure; path=/ However at parsing the cookies, 3 cookies are recognized, i.e.: - sessionid=4241de88-1c21-4f39-b7b7-f50a87d6a828 - 0x409 - cadata=1,kou8Vc9O9nrV4YRnTwVz6QMNbuiWuIg2NprLOkMT4NEcDtGkSTB2P9ORB2QUHsu P+E2OfwYC4rWCMgGe The 0x409 part should not be a cookie but should be a part of the sessionid cookie!!! The ideal solution would be to correct this in the cookie parser. Because I am no expert in cookies and httpclient, Ii changed the httpstate class in such a way that I can manipulate the cookies. See path below. Jan -- [web] http://www.odi.ch/ [blog] http://www.odi.ch/weblog/ [pgp] key 0x81CF3416 finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Declaring end of life for 2.0
Folks, I suggest we declare the HttpClient 2 branch as end of life, now that we have 3.0 out and are working on HttpComponents. That would essentially mean we won't make changes to the 2.0 codebase any more (which is already a fact) and there will be no more 2.x releases. It would also mean we can take the 2.0 site offline with the advent of the HttpComponents site. This should encourage more people to switch to 3.0. What do you think? Odi -- [web] http://www.odi.ch/ [blog] http://www.odi.ch/weblog/ [pgp] key 0x81CF3416 finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cookie processing
Jan, If you think this is an error, please submit a JUnit TestCase that demonstrates the problem. Thanks Ortwin Glück Hoef, Jan wrote: However the httpclient code generates only 3 cookies out of it, not 4. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] HttpClient 2 end of life
I would like to declare the HttpClient 2 branch as end of life. This has the following consequences: * The HttpClient 2 code base is officially unmaintained (dormant) * There will be no more HttpClient 2.x releases * The HttpClient 2.0 site will be taken offline as soon as the HttpCompontents site is set up. -- [ ] +1, yes, declare it end of life [ ] -1, no, keep it alive because -- Votes are binding from HttpClient committers only. Other votes are informational only. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] HttpClient 2 end of life
+1 Ortwin Glück wrote: I would like to declare the HttpClient 2 branch as end of life. This has the following consequences: * The HttpClient 2 code base is officially unmaintained (dormant) * There will be no more HttpClient 2.x releases * The HttpClient 2.0 site will be taken offline as soon as the HttpCompontents site is set up. -- [ ] +1, yes, declare it end of life [ ] -1, no, keep it alive because -- Votes are binding from HttpClient committers only. Other votes are informational only. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- [web] http://www.odi.ch/ [blog] http://www.odi.ch/weblog/ [pgp] key 0x81CF3416 finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 38561] New: - Connection gets closed on GET operation
sebb wrote: Ideally the links ought to be fixed by changing whatever Maven uses to generate the site, but I don't know where that is. That used to be a bug in a plugin: http://jira.codehaus.org/browse/MPXDOC-186 Upgrade xdoc plugin to Version 1.10 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Http basic auth through proxy
Hi,
Can you post the relavant section of the log file?
http://jakarta.apache.org/commons/httpclient/logging.html
Cheers
Ortwin Glück
Azwan Adli Abdullah wrote:
Hi All,
I'm having problem to post to http server which has basic auth enabled and
java client is going through proxy. I got response authentication
failure. It seems that no username/password sent to that http server.
When i remove the proxy, it is ok.
The proxy i'm using is from apache http server 1.3.x, the config is as below:
ProxyRequests On
Directory proxy:*
Order Deny,Allow
Allow from all
/Directory
My code is as below:
httpClient = new HttpClient();
if (useProxy) {
HostConfiguration hc = httpClient.getHostConfiguration();
hc.setProxy(getFwdProxyHost(), Integer.parseInt(getFwdProxyPort()));
}
httpClient.getState().setAuthenticationPreemptive(true);
Credentials defaultcreds = new UsernamePasswordCredentials(httpUsername,
httpPassword);
httpClient.getState().setCredentials(realm, hostName, defaultcreds);
I'm using commons-httpclient-2.0.2.jar. Is there anyone facing this
problem and solved it?
Thanks.
--
[web] http://www.odi.ch/
[blog] http://www.odi.ch/weblog/
[pgp] key 0x81CF3416
finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [http-core] test case fails
Oleg Kalnichevski wrote: Generally I think this is a very bad practice to catch runtime exceptions indiscriminately, because you may well end up catching NPE and OutOfMemory exceptions as well, which to me should clearly be fatal and should result in the termination of the process (thread) Oleg That is a very important point, Oleg. I have always been telling this to my development team. Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Applications page
Roland, Roland Weber wrote: 1. Our license is APL, not GPL. We don't discriminate closed source just because it's closed. It didn't intend to sound like a GPL evangelist, because I really am not. I live of writing commercial closed source software and thus can not use GPL components. But asking closed source projects for a little background information that makes use believe they actually use HttpClient is fair. Yeah, sounds fair for me. 2. The Applications page is a marketing resource, not a development resource. We were glad to get the entries there and should not start to throw them out now that we can afford to get picky. How about setting up a new Featured Projects page as a developer resource? A maximum of 10 projects there, open source only. That I find a nice solution. cheers, Roland PS: The german DVD boxes of Six Feet Under are at series 3 only, series 4 is currently broadcasting :-) SFU in German is horrible. :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Applications page
Oleg Kalnichevski wrote: Odi, Quite frankly, I do not think we have resources to police the content of this page. We can't and we won't. Let us not even pretend that we do. Well, I could just do it. It's not too much work. We put this page together at the very beginning of my time with project when we felt HttpClient needed all promotion it could get. This is no longer the case. I know. That's why I am proposing a change. Still, we should not selectively remove projects from the list because we think they do not meet new criteria. Our needs have changed. The list has changed. I feel a need to act. We should either completely remove this page That is an option of course and I won't object if we vote for this option. But I also see the benefits of this list. or keep it open to anyone who can produce a material evidence of using HttpClient ah, now we're talking :-) * a reference on the web site * commons-httpclient.jar in the download bundle, source code I am okay with these rules. We should not require people to qualify for the privilege in my opinion. HttpClient is probably used in hundreds of (small) projects. If all of them wanted to get listed here we would have a serious problem. But okay, at least your two criteria weed out some of them. And I guess you hereby agree that the link I removed really doesn't qualify. Of course we have the freedom to remove offending entries like open source e-mail harvesters, spam robots, viagra sites claiming to use HttpClient etc. :-) Oleg PS: What keeps you up so late? ;-) I just finished the fourth series of Six Feet Under on DVD :-) Have to check out if there is a fifth... Cheers Odi PS. Opinions from non-committers are also welcome! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta-httpclient Wiki] Update of HttpClientPowered by Eric Hollander
An example of a VERY interesting entry: they are maintaining an actual fork! Apache Wiki wrote: + [http://chiralsoftware.net/drag-and-drop-file-upload.html ChiralUpload] + An applet which allows users to drag-and-drop files to upload them. Chiral Software also maintains an applet fork of HttpClient, which allows smaller applet jars. + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta-httpclient Wiki] Update of HttpClientPowered by LarryOgrodnek
Nice try, spammer. Apache Wiki wrote: + + The following websites use HttpClient. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta-httpclient Wiki] Update of HttpClientPowered by LarryOgrodnek
Sam, It looked like Spam to me. Sorry for this. Still I prefer not to include this link in the list. See my follow-up email shortly. Ortwin Glück Sam Berlin wrote: Err -- that wasn't actually spam. I asked Larry to add that section, based on the fact that Lucene had a The following websites use Lucene, and he felt uncomfortable adding a website in a section that seemed most project-powered. Sam On 1/25/06, Ortwin Glück [EMAIL PROTECTED] wrote: Nice try, spammer. Apache Wiki wrote: + + The following websites use HttpClient. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Applications page
Fellows, This issue (quoted below) is most unfortunate. I think we should seriously think about establishing some basic rules for links to be included in our list of Applications. Right now there are none. Following are a few thoughts: What are the goals of this list? The list is for people evaluating HttpClient: Seeing other projects using HttpClient creates confidence. This is marketing for us. The list is also a bit of advertisement for other projects: If they are listed they get a higher Google page rank. The list is useful to developers: They may find open source projects using HttpClient here and thus may learn from their code how to best use HttpClient in different scenarios. This creates a problem with closed source projects: There is no way to verify that they actually use HttpClient at all. Developers can not learn from closed source code. Still the project gets a higher page rank. That seems unfair to me. The size of the list also creates a problem: The human brain can not deal with it. Developers looking for interesting projects get lost. It is not obvious from the list if a project is trivial or sophisticated. Personally I prefer a much shorter list with high quality entries. I would like to propose some rules such as: A project qualifies for the list if all of the following conditions are met: * The project source code is available online (proves use, enables learning) * The project source code where HttpClient is used has example quality (excludes bad examples) * HttpClient is an important part of the project (shortens list, excludes uninteresting uses) The description of the entry should contain: * what does the software do * what does HttpClient do in the software * how and where (packages/classes) is HttpClient being used Please post your opinions. Ortwin Glück Sam Berlin wrote: Err -- that wasn't actually spam. I asked Larry to add that section, based on the fact that Lucene had a The following websites use Lucene, and he felt uncomfortable adding a website in a section that seemed most project-powered. Sam On 1/25/06, Ortwin Glück [EMAIL PROTECTED] wrote: Nice try, spammer. Apache Wiki wrote: + + The following websites use HttpClient. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FilePart Buffer Size of 4096
S. Aden wrote: There seems to be quite a lot of magic numbers being used in the HTTP Client 3.0 code. Could you please submit a list of the individual problems? One that caught my eye in particular is the hard coded buffer size of 4096 in the FilePart class's sendData() method. The content of the file stream is read in 4096 byte chunks and then written to the output stream (socket). I was wondering if there is any reason for doing this? Perhaps the buffer size should be configurable property of the FilePart class? Fair enough. Feel free to file a bug report. See http://jakarta.apache.org/commons/httpclient/issue-tracking.html Ortwin Glück -- [web] http://www.odi.ch/ [blog] http://www.odi.ch/weblog/ [pgp] key 0x81CF3416 finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FilePart Buffer Size of 4096
Aden, Sorry man, I can not follow your argument. Your words are a complete mess. This is just a simple buffer. Your application will not notice whether the buffer size is 4096 or 4560 bytes. You won't notice any remarkable difference at all as long as the buffer size is larger than a TCP packet size (i.e. the number of transmitted packets is minimal). If you still have doubts please do performance measurements and submit data that proves claims you make. Ortwin Glück S. Aden wrote: Correct me if I am wrong but if a client sends 4096 bytes and the server only reads in 1024 bytes chunks there will be 3072 (4096-1024=3072) bytes left in the server's request input stream. The remaining 3072 bytes has to be read before the next chunk of data the client sent will be readable from the servers request input stream. This is inefficient in that if you really wanted to send data in 4096 byte chunks and read in 4096 byte chunks then you'd have to buffer the server's request input stream yourself. My current objective is to send Base64 encoded content I need to send the content in 4560 byte chunks. The reason for doing this is because decoding 4560 bytes produces the expected result. Basically I don't want to buffer the content just to make sure I have right number bytes before I do a Base64 decode operation. -Aden - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why is Part Content-Length Missing?
Aden, It's correct that multipart MIME is unsafe in that respect. On the other hand it allows to stream data whose size is not known beforehand. Unfortunately HttpClient's multipart implementation does not allow adding of custom headers easily. You may exchange it with a different implementation however. Ortwin Glück S. Aden wrote: My problem is that while it is highly unlikely that the boundary string will appear in the content itself there is no guarantee that it won't unless you Base64 encode the content you're sending (dash will never appear in Base64 encoded content). What I really wanted to do is to add another level of assurance if I choose not to encode the content by adding a Content-Length header attribute for each part so that I am not relying on only the boundary string to tell me when the next part begins. -Aden - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: http-async use cases
Roland Weber wrote: The problem I see is to get CPU time for sending requests and detecting responses. We will always need some kind of background thread to do that. NIO can help to reduce the number of background threads, but that in turn reduces concurrency: the connections will compete for processing time from the shared threads. That's why I think that there should be different options: * IO+many threads for best response times * NIO+few threads for resource efficiency This problem could be addressed by dynamic allocation of threads: Start with one thread that handles connections with NIO. This is done in a selector loop. Continuously measure the wait-time vs. the processing time. If this ratio exceeds a certain limit for a long enough time then spawn another processing thread. If the ratio is low enough for a long enough time then reduce the amount of threads. It's not so easy to implement probably, but if done well can make an extremely scalable system. Odi -- [web] http://www.odi.ch/ [blog] http://www.odi.ch/weblog/ [pgp] key 0x81CF3416 finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] HttpClient: possibility to specify port number in Host headers
Jasper, thanks a lot for this follow up. So you are actually doing NAT and my scenario was not too wrong. And apparently a different virtual port references a different document. So Oleg, this means there effectively *is* such a feature as a port and we should therefore provide access to it. I'll open a new issue report in a minute. Cheers Ortwin Glück Jasper van Zandbeek wrote: Here's the situation for which we want to use virtual port numbers: We use a load balancer that connects to the HTTP server and the HTTP server connects to the application server. We use port translation in our load balancer. So when e.g. a client connects to 90 of the load balancer, the load balancer connects to port 100 of the HTTP server. The load balancer doesn't change the Host request header, so in the host request header is still the original virtual host name and port, in this case port 90. For this reason, the virtual hosts of the HTTP server and application server are configured based on the external port numbers, so in this case port 90. For test purposes, we sometimes want to connect directly to the HTTP server or the application server, bypassing the load balancer. To do this, we need to connect to the same port as the load balancer would, in this example port 100, but the host header of this request should be the same as if the request would go through the load balancer, so in this example port 90, because the HTTP server and application server's virtual hosts are configured for this port. Jasper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What's wrong with this code
Francois, The log suggests that the second request was successfully sent to the server. The client is waiting for a response. I can not tell you why your server does not respond. Please debug the server side. Apart from that I noticed two things: 1. You are using JDK 1.4.1 which may be buggy. Please use an uptodate JDK 1.4.2 if possible. 2. You are still using HttpClient 2. We have just released HttpClient 3 which fixes numerous bugs. Consider upgrading but note the slight API changes. Cheers Ortwin Glück - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Post Method - Content Length Header
Gerdes, Tom wrote: Is there anyway to get a method added .getRequestBodyAsString() to the Post Class that allows us to look at the post request body in the same way the we can look at the response body using the .getResponseBodyAsString() method for the GetMethod() class. It would sure help with debugging. Currently not. The problem is that the request data may only be available once. Use the wirelog or a packet sniffer like Ethereal for debugging. Ortwin Glück PS. If you choose to continue postings with an inappropriate subject line my mailbox will direct your subsequent email to /dev/null. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Code Review Http-Core
Yes, Oleg, that is exactly what I had in mind. I find it a much cleaner
design.
Thanks
Odi
Oleg Kalnichevski wrote:
Odi,
Do you think this will make a better interface?
Oleg
interface HttpClientConnection extends HttpConnection {
...
void sendRequestHeader(HttpRequest request) throws HttpException, IOException;
void sendRequestEntity(HttpEntityEnclosingRequest request) throws
HttpException, IOException;
HttpMutableResponse receiveResponseHeader(HttpParams params) throws
HttpException, IOException;
HttpEntity receiveResponseEntity(HttpParams params) throws HttpException,
IOException;
}
interface HttpServerConnection extends HttpConnection {
...
HttpMutableRequest receiveRequestHeader(HttpParams params) throws HttpException, IOException;
HttpEntity receiveRequestEntity(HttpParams params) throws HttpException,
IOException;
void sendResponseHeader(HttpResponse response) throws HttpException,
IOException;
void sendResponseEntity(HttpResponse response) throws HttpException, IOException;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: SV: Slow to open connection after an hour or so
Kim B. Andersen wrote: httpclient client = new hhtpClient(); method = new getMethod(url); client.execute(method); ... ... method.releaseconnection(); Please put a finally clause around releaseConnection, just to make sure it is called even when an exception occurs. How can I see if the pool is empty? If you get a line in the log like: Unable to get a connection, waiting... then the pool is empty. * Maybe attach a debugger / profiler or use jconsole I have never played with these tools so I don't no how at the moment. I will try to look into it, but if you can recommend some website to read or describe how to - I would appreciated alot. Sorry, we are not offering free online courses in software engineering. Please use other resources. First hour 2006/01/03 14:46:49:926 CET [DEBUG] HttpConnection - Open connection to fastnetselvbetjening.tdconline.dk:443 2006/01/03 14:46:50:038 CET [DEBUG] header - GET /Krump/Alivetest.do?ws HTTP/1.1[\r][\n] After the first hour 2006/01/04 07:58:50:230 CET [DEBUG] HttpConnection - Open connection to fastnetselvbetjening.tdconline.dk:443 2006/01/04 07:58:59:230 CET [DEBUG] header - GET /Krump/Alivetest/alivetester1.html HTTP/1.1[\r][\n] That's definitely helpful. The connection pool is apparently NOT the problem. But it takes longer when actually opening the connection. As to why that happens I can only speculate. Do you have control over the target host? Is it possible that they perform some dynamic connection rate limiting? Cheers Ortwin Glück - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] HttpClient: possibility to specify port number in Host headers
Oleg Kalnichevski wrote: Jasper, I believe I can vaguely tell the difference between numbers 80 and 100. The point I am trying to make is that there is no such thing as a 'virtual' port. The target server either listens on a port or it does not. Take a look at the HTTP spec. There is no mentioning of the concept of a virtual port in it Oleg You may be wrong here, Oleg. The Host header may contain a port number. The spec only says this port number must match the resource being requested, as obtained from the original URI given by the user or referring resource. That's not necessarily the port the server is listening on. Imaging a cascade of Apache servers that forward requests using the ProxyPass directive. Jasper, can you explain the scenario in which you are encountering the need for this feature? Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Downloadproblems
Tom, I can't reproduce this. It downloads okay from mirror.switch.ch. Ortwin Glück PS: Next time please don't reply to an email that is unrelated to your problem but instead create a new one. Gerdes, Tom wrote: I was trying to download the binary version of httpclient_3.0 from the httpclient web site and the download get halfway through and stalls. I tried to download from several different mirrors with the same result. Can anyone helo me with this? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
