This is going off on a slight tangent, but the reason for the applet to use
the browser for the SSL connection is that otherwise the applet has to
download JSSE to have the HttpsURLConnection class. By using
URL.openConnection(), the applet doesn't have to worry about whether it's
SSL or not, and doesn't have to deal with a JSSE download - it just takes
advantage of the existing SSL support in the browser.
Rick
|---------+---------------------------->
| | Daniel Rall |
| | <dlr@finemaltcodi|
| | ng.com> |
| | Sent by: |
| | dlr@finemaltcodin|
| | g.com |
| | |
| | |
| | 02/26/2002 11:04 |
| | AM |
| | Please respond to|
| | rpc-dev |
| | |
|---------+---------------------------->
>-----------------------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: Netscape browser/applet problem with SSL
|
>-----------------------------------------------------------------------------------------------------------------------|
"Rick Johnston" <[EMAIL PROTECTED]> writes:
> Very interesting. This would say to me that XMLRPC cannot be used in an
> applet running in a Netscape browser with an SSL connection, since the
> browser usually doesn't supply valid content-length header information
> (even when the java code attempts to do so). Also, the content-type in
> this configuration is as likely to be null as any other value. We had to
> remove some validation code from our servlet because of this problem.
Why not have the applet make the HTTP connection to the server itself
(i.e. why invovle the browser at all)?
> I guess this is one of the problems of working with a frozen standard.
The
> rest of the world doesn't necessarily care whether people can use that
> standard.
Yeah, I may end up forking away from the standard myself.
> Just so I'm clear, can you remind me of the policy for people to modify
> this type of behavior in our own implementations?
Have at it (http://www.apache.org/LICENSE.txt has the details).
Dan
