Re: importing certs with private key into keystore
Hi,
What I did was this:
1) I created a keystore with a new private key via:
keytool -genkey
... which will create a JKS keystore
2) I then load the PKCS12 keystore
KeyStore inputKeyStore = KeyStore.getInstance( PKCS12 );
inputKeyStore.load(new
FileInputStream(replace_with_your_PKCS12_keystore.p12),
replace_with_your_passphrase.toCharArray());
3) I then load the JKS keystore
KeyStore outputKeyStore = KeyStore.getInstance( JKS );
outputKeyStore.load( new
FileInputStream(replace_with_your_JKS_keystore.jks),
replace_with_your_JKS_passphrase.toCharArray());
4) I then load the certs from the PKCS12 and store them into the JKS
keystore:
Enumeration aliases = inputKeyStore.aliases();
String alias;
Certificate certs[];
Certificate cert;
X509Certificate x509cert;
Key key = null;
while( aliases.hasMoreElements() ) {
alias = (String) aliases.nextElement();
System.out.println( Alias: + alias +
=== );
if( inputKeyStore1.isKeyEntry( alias ) ) {
key = inputKeyStore1.getKey( alias,
wcapcertpreconfig37.toCharArray() );
System.out.println( Private Key Type: +
key.getClass().getName() );
System.out.println( Private Key Algorithm: +
key.getAlgorithm() );
System.out.println( Private Key Format: + key.getFormat() );
}
certs = inputKeyStore.getCertificateChain( alias );
System.out.println( Certificate chain has + certs.length +
entries. );
for( int i = 0 ; i certs.length; i++ ) {
cert = certs[ i ];
System.out.println( --- );
System.out.println( \tType: + cert.getType() );
System.out.println( \tIsKey: + inputKeyStore1.isKeyEntry(
alias ));
System.out.println( \tIsCertificate: +
inputKeyStore1.isCertificateEntry( alias ));
if( cert instanceof X509Certificate ) {
x509cert = ( X509Certificate ) cert;
System.out.println( \tSubject: +
x509cert.getSubjectDN().getName() );
System.out.println( \tIssuer: +
x509cert.getIssuerDN().getName() );
}
System.out.println( \tPublic Key Algorithim: +
cert.getPublicKey().getAlgorithm() );
System.out.println( \tPublic Key Format: +
cert.getPublicKey().getFormat() );
}
outputKeyStore.setKeyEntry( alias, key,
replace_with_your_JKS_passphrase.toCharArray(), certs );
}
System.out.println( Saving to new keystore ... );
outputKeyStore.store( new FileOutputStream(
replace_with_your_JKS_keystore.jks ),
replace_with_your_JKS_passphrase.toCharArray() );
System.out.println( New keystore saved );
5) I then repeat the same process for each PKCS12 file.
Tim Wild wrote:
Hi,
Can anyone tell me how to get my client certificate, complete with
private key, into my Java keystore? I have my openssl generated
certificate and private key in .pem files. I can get it in sometimes,
but never with private key, and if I do get it in I get errors when I
try to use Java to present the client cert. I've read LOTS of guides
on the web, but none seem accurate.
I managed this yesterday, but I can't work out how I did it... this
key/keystore/certificate stuff's driving my crazy!
Many thanks for any ideas
Tim
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
--
Jesus M. Salvo Jr.
Mobile Internet Group Pty Ltd
(formerly Softgame International Pty Ltd)
M: +61 409 126699
T: +61 2 94604777
F: +61 2 94603677
PGP Public key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xC0BA5348
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: client certs - how to choose which cert to use?
Tim Wild wrote: Hi all, Using a link to Sun code that a few people have posted before, I have client authentication working using HttpClient by creating my own SecureProtocolSocketFactory. The problem i'm having is that it seems to automatically choose a certificate without asking me which one to use. Does anyone know how to modify the following code to retrieve a cert by name? I came across that same problem before. My answer is: You don't. If you have multiple client certificates, what you should do is combine all of them into one keystore. PKCS12 only allows you to have one, so you have to put all your PKCS12 certificates into a JKS keystore. And then, you dont have to do the code that you showed earlier. All you have to do is specify your JKS keystore filename via the system property java.net.ssl.keyStore and the passphrase for the keystore via java.net.ssl.keyStorePassword and then specify that JKS for the property java.net.ssl.keyStoreType Even a way to work out which client cert is loaded would be great. Thanks Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: client certs - how to choose which cert to use?
Tim Wild wrote: Thanks Jesus, I gave this a try, but I think I missed something, as it didn't work - I got a SSLHandshakeException: with the message handshake_failure, indicating that the client certificate hadn't been presented. What JDK are you using ? If you are using JDK 1.3, then you have to add java.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol to your system property Also, add javax.net.debug=all to your system property so that at least you can see what's happening. I provided those parameters to the JVM and used the HttpClient as usual, simply specifying an https server. I also tried specifying the SSLProtocolSocketFactory. Do I still need to use a SecureProtocolSocketFactory, or should the default one work? If the default one should work, could you think what I might have missed? Thanks Tim Jesus M. Salvo Jr. wrote: Tim Wild wrote: Hi all, Using a link to Sun code that a few people have posted before, I have client authentication working using HttpClient by creating my own SecureProtocolSocketFactory. The problem i'm having is that it seems to automatically choose a certificate without asking me which one to use. Does anyone know how to modify the following code to retrieve a cert by name? I came across that same problem before. My answer is: You don't. If you have multiple client certificates, what you should do is combine all of them into one keystore. PKCS12 only allows you to have one, so you have to put all your PKCS12 certificates into a JKS keystore. And then, you dont have to do the code that you showed earlier. All you have to do is specify your JKS keystore filename via the system property java.net.ssl.keyStore and the passphrase for the keystore via java.net.ssl.keyStorePassword and then specify that JKS for the property java.net.ssl.keyStoreType Even a way to work out which client cert is loaded would be great. Thanks Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Persistent HTTPS connections
Hi Oleg,
Thanks for that. I have now implemented my own MethodRetryHandler and
got rid of my custom loop / retry.
Cleaner log files for my application as well.
John
Kalnichevski, Oleg wrote:
John,
Please correct me if I am wrong (which may well be the case) SO_TIMEOUT only affects socket read operations. I thought it had nothing to do with SSL inactivity timeout. But it looks like it might.
There's another way to deal with recoverable exceptions. You can provide a custom implementation of MethodRetryHandler
http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/httpclient/MethodRetryHandler.html
The default implementation of the MethodRetryHandler is quite conservative. It does not allow the method to be retried if the request has been transmitted in its entirety.
http://jakarta.apache.org/commons/httpclient/xref/org/apache/commons/httpclient/DefaultMethodRetryHandler.html#62
Oleg
-Original Message-
From: Jesus M. Salvo Jr. [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 13, 2004 7:40
To: [EMAIL PROTECTED]
Subject: Persistent HTTPS connections
Using HttpClient 2.0
JDK 1.4.2_04 on Fedora
Is there anything special that I have to do to make use of persistent
HTTP(S) connections with HttpClient other than using
MultiThreadedHttpConnectionManager ?
Basically, what I am doing is the following ( more explanation after the
snippet of the source code ):
MultiThreadedHttpConnectionManager connectionManager =
new MultiThreadedHttpConnectionManager();
connectionManager.setConnectionStaleCheckingEnabled( true );
connectionManager.setMaxConnectionsPerHost( 10 );
connectionManager.setMaxTotalConnections( 100 );
this.httpClient = new HttpClient( connectionManager );
this.httpClient.setConnectionTimeout( 3 );
this.httpClient.setTimeout( 3 );
and then within a thread, the thread does this:
String content;
HttpMethod method;
try {
method = new PostMethod( connectionURL );
method.setDoAuthentication( true );
method.setRequestHeader( Content-Type, contentType + ;
charset= + this.outboundEncoding);
if( method instanceof PostMethod ) {
PostMethod postMethod = (PostMethod) method;
postMethod.setRequestBody( content );
}
int responseCode = this.httpClient.executeMethod( method );
String response = method.getResponseBodyAsString();
.
}
catch( Exception ex ) {}
finally {
if( method != null ) method.releaseConnection();
}
What I am doing, then, from a JUnit test class, is:
1) Send one HTTP POST to a URL, which works and I get the response.
2) Sleep for 40 seconds ( which is greater than the SO_TIMEOUT of 30
seconds )
3) Send another HTTP POST to the same URL.
What I am seeing with ethereal is that, after 30 seconds of no activity
( no TCP ACKs whatever on the socket ), the web server sends a a TLS alert.
So what actually happens is this:
1) Send one HTTP POST to a URL, which works and I get the response.
2) Sleep for 40 seconds ( which is greater than the SO_TIMEOUT of 30
seconds )
3) Web server sends a TLS alert after 30 seconds of inactivity. Web
server sends a TCP FIN, Java sends a TCP ACK _only_ .
4) Wake up from sleep at the 40 second mark, send another HTTP POST to
the same URL.
5) Receive a TLS alert instead of a HTTP response. The TLS alert
according to JSSE's debug mode is:
main, RECV TLSv1 ALERT: warning, close_notify
main, called closeInternal(false)
main, SEND TLSv1 ALERT: warning, description = close_notify
6) HttpClient throws an HttpRecoverableException, shown below:
org.apache.commons.httpclient.HttpRecoverableException:
org.apache.commons.httpclient.HttpRecoverableException: Error in parsing
the status line from the response: unable to find line starting with HTTP
Question is, was I correct in initially assuming that
MultiThreadedHttpConnectionManager should have handled this case ?
e.g... .detected that the exception, and retried the HTTP POST by
creating a new HTTPS socket ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
***
The information in this email is confidential and may be legally privileged. Access
to this email by anyone other than the intended addressee is unauthorized. If you are
not the intended recipient of this message, any review, disclosure, copying,
distribution, retention, or any action taken or omitted to be taken in reliance on it
is prohibited and may be unlawful. If you are not the intended recipient, please
reply to or forward a copy of this message to the sender and delete the message, any
attachments, and any copies thereof from your system
Re: Persistent HTTPS connections
One small thing though. Why is setMethodRetryHandler() defined in
HttpMethodBase class instead of the HttpMethod interface ?
Jesus M. Salvo Jr. wrote:
Hi Oleg,
Thanks for that. I have now implemented my own MethodRetryHandler and
got rid of my custom loop / retry.
Cleaner log files for my application as well.
John
Kalnichevski, Oleg wrote:
John,
Please correct me if I am wrong (which may well be the case)
SO_TIMEOUT only affects socket read operations. I thought it had
nothing to do with SSL inactivity timeout. But it looks like it might.
There's another way to deal with recoverable exceptions. You can
provide a custom implementation of MethodRetryHandler
http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/httpclient/MethodRetryHandler.html
The default implementation of the MethodRetryHandler is quite
conservative. It does not allow the method to be retried if the
request has been transmitted in its entirety.
http://jakarta.apache.org/commons/httpclient/xref/org/apache/commons/httpclient/DefaultMethodRetryHandler.html#62
Oleg
-Original Message-
From: Jesus M. Salvo Jr. [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 13, 2004 7:40
To: [EMAIL PROTECTED]
Subject: Persistent HTTPS connections
Using HttpClient 2.0
JDK 1.4.2_04 on Fedora
Is there anything special that I have to do to make use of persistent
HTTP(S) connections with HttpClient other than using
MultiThreadedHttpConnectionManager ?
Basically, what I am doing is the following ( more explanation after the
snippet of the source code ):
MultiThreadedHttpConnectionManager connectionManager =
new MultiThreadedHttpConnectionManager();
connectionManager.setConnectionStaleCheckingEnabled( true );
connectionManager.setMaxConnectionsPerHost( 10 );
connectionManager.setMaxTotalConnections( 100 );
this.httpClient = new HttpClient( connectionManager );
this.httpClient.setConnectionTimeout( 3 );
this.httpClient.setTimeout( 3 );
and then within a thread, the thread does this:
String content;
HttpMethod method;
try {
method = new PostMethod( connectionURL );
method.setDoAuthentication( true );
method.setRequestHeader( Content-Type, contentType + ;
charset= + this.outboundEncoding);
if( method instanceof PostMethod ) {
PostMethod postMethod = (PostMethod) method;
postMethod.setRequestBody( content );
}
int responseCode = this.httpClient.executeMethod( method );
String response = method.getResponseBodyAsString();
.
}
catch( Exception ex ) {}
finally {
if( method != null ) method.releaseConnection();
}
What I am doing, then, from a JUnit test class, is:
1) Send one HTTP POST to a URL, which works and I get the response.
2) Sleep for 40 seconds ( which is greater than the SO_TIMEOUT of 30
seconds )
3) Send another HTTP POST to the same URL.
What I am seeing with ethereal is that, after 30 seconds of no activity
( no TCP ACKs whatever on the socket ), the web server sends a a TLS
alert.
So what actually happens is this:
1) Send one HTTP POST to a URL, which works and I get the response.
2) Sleep for 40 seconds ( which is greater than the SO_TIMEOUT of 30
seconds )
3) Web server sends a TLS alert after 30 seconds of inactivity. Web
server sends a TCP FIN, Java sends a TCP ACK _only_ .
4) Wake up from sleep at the 40 second mark, send another HTTP POST to
the same URL.
5) Receive a TLS alert instead of a HTTP response. The TLS alert
according to JSSE's debug mode is:
main, RECV TLSv1 ALERT: warning, close_notify
main, called closeInternal(false)
main, SEND TLSv1 ALERT: warning, description = close_notify
6) HttpClient throws an HttpRecoverableException, shown below:
org.apache.commons.httpclient.HttpRecoverableException:
org.apache.commons.httpclient.HttpRecoverableException: Error in parsing
the status line from the response: unable to find line starting with
HTTP
Question is, was I correct in initially assuming that
MultiThreadedHttpConnectionManager should have handled this case ?
e.g... .detected that the exception, and retried the HTTP POST by
creating a new HTTPS socket ?
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
***
The information in this email is confidential and may be legally
privileged. Access to this email by anyone other than the intended
addressee is unauthorized. If you are not the intended recipient of
this message, any review, disclosure, copying, distribution,
retention, or any action taken or omitted to be taken in reliance on
it is prohibited and may be unlawful. If you are not the intended
recipient, please reply to or forward a copy of this message to the
sender and delete the message, any
Re: Persistent HTTPS connections
Some clarifications below. Jesus M. Salvo Jr. wrote: What I am seeing with ethereal is that, after 30 seconds of no activity ( no TCP ACKs whatever on the socket ), the web server sends a a TLS alert. So what actually happens is this: 1) Send one HTTP POST to a URL, which works and I get the response. 2) Sleep for 40 seconds ( which is greater than the SO_TIMEOUT of 30 seconds ) 3) Web server sends a TLS alert after 30 seconds of inactivity. Web server sends a TCP FIN, Java sends a TCP ACK _only_ . At this point, local socket is in CLOSE_WAIT state. 4) Wake up from sleep at the 40 second mark, send another HTTP POST to the same URL. 5) Receive a TLS alert instead of a HTTP response. The TLS alert according to JSSE's debug mode is: main, RECV TLSv1 ALERT: warning, close_notify main, called closeInternal(false) main, SEND TLSv1 ALERT: warning, description = close_notify Item (5) is actually not the webserver sending a TLS alert, but JSSE sending the TLS alert 6) HttpClient throws an HttpRecoverableException, shown below: org.apache.commons.httpclient.HttpRecoverableException: org.apache.commons.httpclient.HttpRecoverableException: Error in parsing the status line from the response: unable to find line starting with HTTP Question is, was I correct in initially assuming that MultiThreadedHttpConnectionManager should have handled this case ? e.g... .detected that the exception, and retried the HTTP POST by creating a new HTTPS socket ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Persistent HTTPS connections
Jesus M. Salvo Jr. wrote: Question is, was I correct in initially assuming that MultiThreadedHttpConnectionManager should have handled this case ? e.g... .detected that the exception, and retried the HTTP POST by creating a new HTTPS socket ? What I have done now is, if I get a HttpRecoverableException, I retry the HTTP call. The executeMethod() is therefore in a while loop. I am now to put a hard limit on the number of retries. Just like to ask what have everyone else doing. Is this the best pratice with HttpClient to handle persistent connections ? Regards, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Persistent HTTPS connections
Using HttpClient 2.0
JDK 1.4.2_04 on Fedora
Is there anything special that I have to do to make use of persistent
HTTP(S) connections with HttpClient other than using
MultiThreadedHttpConnectionManager ?
Basically, what I am doing is the following ( more explanation after the
snippet of the source code ):
MultiThreadedHttpConnectionManager connectionManager =
new MultiThreadedHttpConnectionManager();
connectionManager.setConnectionStaleCheckingEnabled( true );
connectionManager.setMaxConnectionsPerHost( 10 );
connectionManager.setMaxTotalConnections( 100 );
this.httpClient = new HttpClient( connectionManager );
this.httpClient.setConnectionTimeout( 3 );
this.httpClient.setTimeout( 3 );
and then within a thread, the thread does this:
String content;
HttpMethod method;
try {
method = new PostMethod( connectionURL );
method.setDoAuthentication( true );
method.setRequestHeader( Content-Type, contentType + ;
charset= + this.outboundEncoding);
if( method instanceof PostMethod ) {
PostMethod postMethod = (PostMethod) method;
postMethod.setRequestBody( content );
}
int responseCode = this.httpClient.executeMethod( method );
String response = method.getResponseBodyAsString();
.
}
catch( Exception ex ) {}
finally {
if( method != null ) method.releaseConnection();
}
What I am doing, then, from a JUnit test class, is:
1) Send one HTTP POST to a URL, which works and I get the response.
2) Sleep for 40 seconds ( which is greater than the SO_TIMEOUT of 30
seconds )
3) Send another HTTP POST to the same URL.
What I am seeing with ethereal is that, after 30 seconds of no activity
( no TCP ACKs whatever on the socket ), the web server sends a a TLS alert.
So what actually happens is this:
1) Send one HTTP POST to a URL, which works and I get the response.
2) Sleep for 40 seconds ( which is greater than the SO_TIMEOUT of 30
seconds )
3) Web server sends a TLS alert after 30 seconds of inactivity. Web
server sends a TCP FIN, Java sends a TCP ACK _only_ .
4) Wake up from sleep at the 40 second mark, send another HTTP POST to
the same URL.
5) Receive a TLS alert instead of a HTTP response. The TLS alert
according to JSSE's debug mode is:
main, RECV TLSv1 ALERT: warning, close_notify
main, called closeInternal(false)
main, SEND TLSv1 ALERT: warning, description = close_notify
6) HttpClient throws an HttpRecoverableException, shown below:
org.apache.commons.httpclient.HttpRecoverableException:
org.apache.commons.httpclient.HttpRecoverableException: Error in parsing
the status line from the response: unable to find line starting with HTTP
Question is, was I correct in initially assuming that
MultiThreadedHttpConnectionManager should have handled this case ?
e.g... .detected that the exception, and retried the HTTP POST by
creating a new HTTPS socket ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question on Timeouts
[EMAIL PROTECTED] wrote:
Hello,
I'm using your product for an application that we're building (that fetches some
HTTP content) and I'm running into an issue where it isn't timing out
..snip...
--This is how we're connecting -
HttpClient client = new HttpClient();
client.setConnectionTimeout (connectionTimeout * 1000);
client.setTimeout (transferTimeout * 1000);
HttpMethod method = new GetMethod(url);
try {
statusCode = client.executeMethod(method);
}
Try specifying an SO_TIMEOUT in milliseconds via HttpClient.setTimeOut()
method.
Otherwise, it will default to whatever is the default SO_TIMEOUT on your
platform.
BTW, does anyone have a compilation / list of the defautl SO_TIMEOUT
values for each platform ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
CLOSE_WAIT, logging
HttpClient RC 2.0 64-bit Solaris 8 JDK 1.3.1_09 I am seeing lots of sockets in CLOSE_WAIT, despite the fact that postMethod.releaseConnection(); is called. This has happened so far against 2 of our ( different ) clients' webservers, mostly to Tomcat / Coyote. The problem with CLOSE_WAIT sockets do not seem to be happening against Orion. What happens in the long run is that I run of file descriptors I am now able to reproduce the same problem against the client's test webservers ... but in turnin on logging, the logging is not being logged on stdout. In order to give meaningful results to this list about my CLOSE_WAIT problem, I wrote a small class and script to replicate the problem, but still no logging. Here is the sample shell script run on cygwin: CLASSPATH=classes CLASSPATH=$CLASSPATH\;/cvs/softgame-latest/development/lib/commons-httpclient.jar CLASSPATH=$CLASSPATH\;/cvs/softgame-latest/development/lib/commons-logging.jar REM CLASSPATH=$CLASSPATH\;/cvs/softgame-latest/development/lib/log4j.jar java \ -Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog \ -Dorg.apache.commons.logging.simplelog.showdatetime=true \ -Dorg.apache.commons.logging.simplelog.log.httpclient.wire=debug \ -Dorg.apache.commons.logging.simplelog.log.org.apache.commons.httpclient=debug \ $JAVA_DEFINES -classpath $CLASSPATH HttpClientTest Help ! Regards, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CLOSE_WAIT, logging
Saw that too ... Having said that, I am actually not reusing an HttpClient instance, and create a new one every time using an empty constructor ... and therefore a new instance of SimpleHttpConnectionManager. All of this happens inside of a method. Now I would assume that, because my instances of HttpClient ( and therefore SimpleHttpConnectionManager ) are inside of a method, that after the method call, they would be out of scope, that the connection / socket should close (!?) John Sam Berlin wrote: The reason this is happening is because the releaseConnection method of HttpMethods does not close the connection, it just returns it to the HttpConnectionManager for reuse by another HttpMethod. A 'Connection: Close' header tells HttpClient that this connection should be closed after the request is made (instead of leaving it open, for further HTTP/1.1 transfers). Because the public API of HttpMethod has no 'close' method, and one would generally expect that, there is a misconception about what releaseConnection does. A suggestion that has been posted here before is adding an 'abort' method to HttpMethod and HttpMethodBase, the contents of which call close() on the underlying HttpConnection. Thanks, Sam On Sunday, December 7, 2003, at 10:31 PM, Jesus M. Salvo Jr. wrote: From a snoop capture, Apache Coyote sent a TCP FIN 20 seconds after the last ACK from the client. But the client did not sent a TCP FIN of its own, leaving the socket in CLOSE_WAIT. The only difference between the Coyote's HTTP response and Orion's HTTP response is that the Orion response have Connection: close in the HTTP header. So, what I did, by using HttpClient, I added: postMethod.addRequestHeader( Connection, close); After the above, I no longer have CLOSE_WAIT sockets. Regards, John Jesus M. Salvo Jr. wrote: HttpClient RC 2.0 64-bit Solaris 8 JDK 1.3.1_09 I am seeing lots of sockets in CLOSE_WAIT, despite the fact that postMethod.releaseConnection(); is called. This has happened so far against 2 of our ( different ) clients' webservers, mostly to Tomcat / Coyote. The problem with CLOSE_WAIT sockets do not seem to be happening against Orion. What happens in the long run is that I run of file descriptors I am now able to reproduce the same problem against the client's test webservers ... but in turnin on logging, the logging is not being logged on stdout. In order to give meaningful results to this list about my CLOSE_WAIT problem, I wrote a small class and script to replicate the problem, but still no logging. Here is the sample shell script run on cygwin: CLASSPATH=classes CLASSPATH=$CLASSPATH\;/cvs/softgame-latest/development/lib/commons- httpclient.jar CLASSPATH=$CLASSPATH\;/cvs/softgame-latest/development/lib/commons- logging.jar REM CLASSPATH=$CLASSPATH\;/cvs/softgame-latest/development/lib/log4j.jar java \ - Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.Simple Log \ -Dorg.apache.commons.logging.simplelog.showdatetime=true \ -Dorg.apache.commons.logging.simplelog.log.httpclient.wire=debug \ - Dorg.apache.commons.logging.simplelog.log.org.apache.commons.httpclien t=debug \ $JAVA_DEFINES -classpath $CLASSPATH HttpClientTest Help ! Regards, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesus M. Salvo Jr. Mobile Internet Group Pty Ltd (formerly Softgame International Pty Ltd) M: +61 409 126699 T: +61 2 94604777 F: +61 2 94603677 PGP Public key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xC0BA5348 - 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] -- Jesus M. Salvo Jr. Mobile Internet Group Pty Ltd (formerly Softgame International Pty Ltd) M: +61 409 126699 T: +61 2 94604777 F: +61 2 94603677 PGP Public key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xC0BA5348 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CLOSE_WAIT, logging
Sam Berlin wrote: That's relying a bit too much on garbage-collection, which can happen at any time. You should never rely on garbage collection to clean up native resources, like open sockets, especially if you're concerned about such low level things as a CLOSE_WAIT state. Thanks, Sam Your're right. Having said that ... it does seems odd that it was done this way and not noted on the documentation. So bottom line is: 1) To implement HTTP/1.1 persistent connections, use a single HttpClient instance that is reused to execute HttpMethods. Assuming of course, that the HTTP response also does not have Connection: close, then we have HTTP persistent connections. 2) In order __not__ to use HTTP/1.1 persistent connections, explicitly add Connection: close HTTP header, specially if a new instance of HttpClient is created everytime. Otherwise, one will run out of files descriptors and get Too many open files exception. John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CLOSE_WAIT, logging
Michael Becke wrote: Agreed. Relying on garbage collection is not really an option. There are only 2 real choices that I can see: 1) add a method on HttpMethod to explicitly close a connection. This would be the simplest solution, but I think it would also defeat the purpose of connection reuse. 2) add a system for cleaning up/closing unused connections, perhaps after some timeout period. This is the better solution I think. Sam, if i remember correctly, you proposed something like this as an addition to the MultithreadedHttpConnectionManager. I would still like to take this idea and make it a little more generic for use with all connections. Hopefully I will find some time to work on this soon. Thanks, Mike OK I dont know how the entire HttpClient works .. but ... doesn't the fact that the socket is in CLOSE_WAIT state ( because the HTTP server sent a TCP FIN ) means that the HttpClient cannot use the socket anymore ? So I guess what I am asking is, does HttpClient detect that the socket to be reused cannot be reused anymore and then closes it and creates a new one ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFE: Method to return an InputStream that includes both HTTPheaders and HTTP body
Definitely ... unless of course setFollowRedirect() is set to false. Ortwin Gl|ck wrote: Jesus M. Salvo Jr. wrote: At the moment, the HttpMethod interface has a method getResponseBodyAsStream() that returns an InputStream of the HTTP body. I need a method that returns the _entire_ HTTP response, including the HTTP headers and body, in a single InputStream. I assume in case of redirection, authentication and the like, you only want the stream from the final request. Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesus M. Salvo Jr. Mobile Internet Group Pty Ltd (formerly Softgame International Pty Ltd) M: +61 409 126699 T: +61 2 94604777 F: +61 2 94603677 PGP Public key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xC0BA5348 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFE: Method to return an InputStream that includes both HTTPheaders and HTTP body
I should qualify that the line containing the HTTP response code _not_ be included in the returned InputStream Ortwin Gl|ck wrote: Jesus M. Salvo Jr. wrote: At the moment, the HttpMethod interface has a method getResponseBodyAsStream() that returns an InputStream of the HTTP body. I need a method that returns the _entire_ HTTP response, including the HTTP headers and body, in a single InputStream. The reason for this is that I need to pass the InputStream to JavaMail's MimeBodyPart constructor, and MimeBodyPart requires the HTTP headers to properly set the MIME headers. Sounds reasonable. Maybe we can find an easy way to do it. We could add another property parseHeaders (default true) to set before you make the request. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesus M. Salvo Jr. Mobile Internet Group Pty Ltd (formerly Softgame International Pty Ltd) M: +61 409 126699 T: +61 2 94604777 F: +61 2 94603677 PGP Public key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xC0BA5348 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Redirect to a different domain not supported?
Did Oleg's work on the redirect made it to alpha3 rc4? Oleg Kalnichevski wrote: Folks I was going to start working on it today. If there are any other takers, please let me know Cheers Oleg On Mon, 2003-02-24 at 07:27, Jeffrey Dever wrote: This is currently on the todo list. Refer to the following bug for more information: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16729 Adrian Sutton wrote: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Redirect to a different domain not supported?
Using Alpha2, when I do an HTTP GET from an Australian ISP to www.google.com with setFollowRedirects set to true, HttpClient client = new HttpClient(); HostConfiguration config = new HostConfiguration(); config.setHost( www.google.com, 80, http ); client.setHostConfiguration( config ); Method method = new GetMethod( / ); method.setFollowRedirects( true ); int returnCode = client.executeMethod( method ); I get: 750 [main] WARN httpclient.HttpMethod - Redirect from host www.google.com to www.google.com.au is not supported I had a look at the code and it was comparing the hostname of the original URL and the hostname of the redirect to URL ... and if they do not match, it does not follow the redirect. Why is this so? Is this specifically prohibited in the HTTP RFC? If yes, why does browsers follow them anyway? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Redirect to a different domain not supported?
I initally thought that commenting out the specific code in
checkValidRedirect() would do it, but the Javadoc for
HttpMethodBase.execute() did say:
* Execute this method. Note that we cannot currently support redirects
* that change the connection parameters (host, port, protocol) because
* we don't yet have a good way to get the new connection. For the time
* being, we just return the redirect response code, and allow the user
* agent to resubmit if desired.
If the host and protocol and ports are the same, it simply calls
HttpMethodBase.setPath() and HttpMethodBase.setQueryString():
//check for redirect to a different protocol, host or port
try {
checkValidRedirect(currentUrl, redirectUrl);
} catch (HttpException ex) {
//LOG the error and let the client handle the redirect
LOG.warn(ex.getMessage());
return false;
}
//update the current location with the redirect location.
//avoiding use of URL.getPath() and URL.getQuery() to keep
//jdk1.2 comliance.
setPath(URIUtil.getPath(redirectUrl.toString()));
setQueryString(URIUtil.getQuery(redirectUrl.toString()));
So I am wondering ... in the case of a different host and port ( and
protocol? ), why not also call setHostConfiguration() ... and possible
also change the HttpConnection that is passed in so that the host and
port are changed?
Adrian Sutton wrote:
This is a remnant from the old design of HttpClient and hopefully will be
removed soon. I'm not sure of the technical details involved, but there is
definitely nothing in the RFC that goes against this and it is a commonly
requested feature.
If you felt like providing a patch I'm sure it would be greatly appreciated.
It's probably worth searching bugzilla (http://nagoya.apache.org/bugzilla)
for the bug related to this and seeing if it's assigned to anyone, I can't
remember if someone was working on it or not.
Regards,
Adrian Sutton, Software Engineer
Ephox Corporation
www.ephox.com
-Original Message-
From: Jesus M. Salvo Jr. [mailto:[EMAIL PROTECTED]
Sent: Monday, 24 February 2003 2:11 PM
To: [EMAIL PROTECTED]
Subject: Redirect to a different domain not supported?
Using Alpha2, when I do an HTTP GET from an Australian ISP to
www.google.com with setFollowRedirects set to true,
HttpClient client = new HttpClient();
HostConfiguration config = new HostConfiguration();
config.setHost( www.google.com, 80, http );
client.setHostConfiguration( config );
Method method = new GetMethod( / );
method.setFollowRedirects( true );
int returnCode = client.executeMethod( method );
I get:
750 [main] WARN httpclient.HttpMethod - Redirect from host
www.google.com to www.google.com.au is not supported
I had a look at the code and it was comparing the hostname of the
original URL and the hostname of the redirect to URL ... and if they do
not match, it does not follow the redirect.
Why is this so? Is this specifically prohibited in the HTTP RFC? If yes,
why does browsers follow them anyway?
-
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]
--
Jesus M. Salvo Jr.
Mobile Internet Group Pty Ltd
(formerly Softgame International Pty Ltd)
M: +61 409 126699
T: +61 2 94604777
F: +61 2 94603677
PGP Public key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xC0BA5348
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
