Hi Nick,
Thanks for your comments, we are developing a cross-platform applet with
1.3+ and running on Windows, OS X, Solaris and when Mozilla fix a particular
bug, Linux so I've been through similar experiences to you. A few of my
comments are below.
>1) VM and Sandbox issues - Since applets need to run in various browser
VM's
>and may or may not be signed they will have different security issues. We
>avoided all these problems by restricting ourselves to Sun's 1.3 or greater
>plug-in with signed applets. This also meant signing the necessary apache
>jars to avoid any SecurityManager issues. Honestly, I don't think the
>HttpClient will work in most applets not in the plugin with signed jars
>simply because of the security violation of opening sockets.
Since HttpClient requires Java 1.2 it wouldn't be possible to run it in any
of the browsers built-in java engines. It is possible to create connections
back to the originating server without being signed, so it would be possible
to use HttpClient, except that we access system properties so that would
throw exceptions. There is a plan to replace the use of system properties
with a configuration class so that would solve that problem.
>2) Proxy Detection - This is simple enough if limited to Sun's plugin, but
>tougher if the desire is to support any environment the applet might run.
>The tough part is that separate protocols (HTTP, HTTPS, FTP) could each use
>different proxy servers if configured to do so. This is not standard
>practice among any of our users, but it could pose a problem for the
>HttpClient in that it only supports 1 proxy for all protocols. I'm not
sure
>if the utility should even attempt to create a correctly configured
>HttpClient instance since 2 clients may be needed to support the different
>proxy servers.
HttpClient doesn't currently have enough support for proxy settings to
detect the proxy correctly, in particular it does not support no proxy
hosts. I have code for this that I could polish up and submit if there was
demand (I think I may have posted it at one stage already actually, but it's
just had a reworking). The most useful thing for an applet utility would be
to detect the proxy settings in as many situations as possible, the best way
currently would be to provide a method similar to:
setProxySettings(HttpState state, URL url)
which would take into account the no proxy hosts and set the proxy
correctly. We'd need to clearly flag which scenario's the function will
work on though (Windows Java 1.3 - 1.4.1 from Sun and 1.3.1 and 1.4.1 on OS
X etc).
>3) Proxy Credentials - To eliminate the constant hassle of bothering the
>user for authentication credentials every time the applet is loaded, we
>store this information encrypted in the user home directory. This raises a
>few concerns since HttpClient requires the cleartext password to be used
>when authenticating to protocols like NTLM. If the password hash could be
>pre-calc'd, stored and later given to HttpClient it would be more secure.
Don't think of the password hash as an encrypted form of the password, think
of it *as* the password because it is 100% equivalent. In other words,
storing the password hash is as secure as storing the plain text password.
>4) Logging - HttpClient requires commons-logging and log4j. It also seems
>to need a log4j-core jar which appears to be optional. This is a little
>extra bulk to download and would be nice to eliminate with a simple logger
>implementation and configuration options.
HttpClient doesn't require log4j, just commons-logging is somewhat screwy
when it tries to automatically identify a logging implementation to use (at
least I haven't worked out the logic). You can help it out be explicitly
telling it to use the SimpleLogger that commons-logging provides. Add the
following line before you do anything with HttpClient or commons-logging.
System.setProperty("org.apache.commons.logging.Log",
"org.apache.commons.logging.impl.SimpleLog");
I put it in a static block at the very top of our applet class so that it
executes straight off the bat and pretty much nothing I do later will cause
a log to be created before it runs. :)
Hope that helps, it my rereading of this post it sounds a bit negative -
it's not meant to be. Your comments are for the most part very accurate and
should be documented, perhaps we should look at doing up a guide for using
HttpClient in applets as part of the new user manual?
Best regards,
Adrian Sutton, Software Engineer
Ephox Corporation
www.ephox.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
