RE: proxy and howto's and some questions.

[Nick Coleman <ni...@leanlogistics.com>]

Hi Oleg,

It's been a month and I'm sorry for the delay.  I've been sidetracked and
also racking my brain to think of what could be relevent for a simple
HttpClient Applet Utility.

Here are the pieces I could tackle, but I'm not sure how exactly I should
approach each item with respect to HttpClient's focus.

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.

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.

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.

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.

We also use SOAP / Axis in the applets for communication.  Although those
are other apache projects, we had to create custom transports using the
httpclient since they do not use multi-threaded HTTP 1.1 connections that
are cached.  The custom transport offers huge improvements.  This is
probably something that we will contribute to these projects.

Looking back at the issues, what I really see is more of a "best practice"
or suggestions rather than an applet utility, with the exception of the
proxy detection code.

-Nick

-----Original Message-----
From: Oleg Kalnichevski [mailto:o.kalnichevski@dplanet.ch] 
Sent: Thursday, February 20, 2003 4:16 PM
To: Commons HttpClient Project
Cc: nick.coleman@leanlogistics.com
Subject: RE: proxy and howto's and some questions.


Hi Nick

> My company is currently using the HttpClient utility in an Applet 
> successfully through proxy servers detected by the browser.  Here is 
> how the proxy settings are configured:

If you were prepared to spend a bit of your time to make a simple applet
utility (with proxy settings detection and other goodies), we would happily
take it as the first contribution to the optional components repository

Cheers

Oleg

RE: proxy and howto's and some questions.

[Oleg Kalnichevski <o....@dplanet.ch>]

Hi Nick

I have always been shunning away from applet programming. Therefore, I
am not in a position to make any judgment here. I think you should just
try to capture those commonalities that you may have observed while
making HttpClient work in an applet. If you end up producing 5 lines of
code with 25 lines of comments on "best practice", it would still be
hugely appreciated and might prove very helpful to some folks out there

Cheers

Oleg

On Wed, 2003-03-19 at 14:47, Nick Coleman wrote:
> Hi Oleg,
> 
> It's been a month and I'm sorry for the delay.  I've been sidetracked and
> also racking my brain to think of what could be relevent for a simple
> HttpClient Applet Utility.
> 
> Here are the pieces I could tackle, but I'm not sure how exactly I should
> approach each item with respect to HttpClient's focus.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> We also use SOAP / Axis in the applets for communication.  Although those
> are other apache projects, we had to create custom transports using the
> httpclient since they do not use multi-threaded HTTP 1.1 connections that
> are cached.  The custom transport offers huge improvements.  This is
> probably something that we will contribute to these projects.
> 
> Looking back at the issues, what I really see is more of a "best practice"
> or suggestions rather than an applet utility, with the exception of the
> proxy detection code.
> 
> -Nick
> 
> -----Original Message-----
> From: Oleg Kalnichevski [mailto:o.kalnichevski@dplanet.ch] 
> Sent: Thursday, February 20, 2003 4:16 PM
> To: Commons HttpClient Project
> Cc: nick.coleman@leanlogistics.com
> Subject: RE: proxy and howto's and some questions.
> 
> 
> Hi Nick
> 
> > My company is currently using the HttpClient utility in an Applet 
> > successfully through proxy servers detected by the browser.  Here is 
> > how the proxy settings are configured:
> 
> If you were prepared to spend a bit of your time to make a simple applet
> utility (with proxy settings detection and other goodies), we would happily
> take it as the first contribution to the optional components repository
> 
> Cheers
> 
> Oleg
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>