-- Roland Weber wrote : Well, you could start with registering a socket factory for the https protocol. You're probably doing that, but it's not in the code you posted. Next, you may want to release the connection EVEN IN CASE OF AN ERROR. I don't see that either. Re-using the HttpClient object is also a good idea, so you are not leaking connections and running into limits of the JSSE provider (or other components). None of this is likely to cause the problem you are reporting, but why take a chance? Then let's start with some of the things you didn't mention. Are you signing the applet and all JARs with it in order to run it? Or are you installing the libraries locally on the client? Is there a proxy involved - I've asked that one before. When registering the https protocol, are you specifying the correct default port? Or does the APP_HOME_URL_PFX specify a port number? That's also not in the code you posted. Commons logging comes with a SimpleLog implementation that writes log output to System.out. That is allowed even for applets.
If you mean like using Oleg's AuthSSLProtocolSocketFactory then no I'm not doing something like that at the moment. In fact, I've just found out about it yesterday and will perhaps try it out, even if that means I will be in effect doing my own socket i/o in the applet and entailing signing the applet and/or messing around with permissions. Well, my applet in its previous form (using Sun's URL + HttpURLConnection, no commons-httpclient) required none of that - no signing, no permission config, no socketfactory designating, just this simple series of calls: make an URL obj -> HttpURLConnection.openConnection() -> HttpURLConnection.getOutputStream(), and write some plain text to it -> HttpURLConnection.getInputStream() and read back the answers from my plain text speaking client cert requiring servlet. The java plugin's (you know, that sun product which allows applets to run within the confines of a browser) version that we use is either 1.4 or 1.5. It is quite simple in terms of my own coding but I know the plugin is doing a lot of work behind the scene to let me use the browser's https channel. In plugin 1.5 (quite new), it will even access the browser's store of client certificates - the user needs to choose (even when there's only ONE qualifying), but we don't need to install one specifically for the plugin or somewhere on the user's pc. Sorry about not answering your earlier questions specifically. No, no proxy is involved. In this new version of my applet where I'm using httpclient, I've commons-httpclient-3.0.1.jar, commons-logging.jar (sorry, maybe I changed the jar filename to not include a version number, silly me!), commons-codec-1.3.jar expanded (in a directory tree of org/apache/...) and included in my applet's jar. That should be good because I'm not getting any class not found errors. You advice about writing clean and safe code is noted and in the real thing I assure you I've or will take care of it - well, in a way, since I can certainly improve it in terms of cleaness and robustness, surely. -- This message was sent on behalf of [EMAIL PROTECTED] at openSubscriber.com http://www.opensubscriber.com/message/httpclient-dev@jakarta.apache.org/4589747.html --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
