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.
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.
Just so I'm clear, can you remind me of the policy for people to modify
this type of behavior in our own implementations?
Rick
|---------+---------------------------->
| | Daniel Rall |
| | <dlr@finemaltcodi|
| | ng.com> |
| | Sent by: |
| | dlr@finemaltcodin|
| | g.com |
| | |
| | |
| | 02/25/2002 02:18 |
| | PM |
| | Please respond to|
| | rpc-dev |
| | |
|---------+---------------------------->
>----------------------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: Netscape browser/applet problem with SSL
|
>----------------------------------------------------------------------------------------------------------------------|
"Rick Johnston" <[EMAIL PROTECTED]> writes:
> I've just had to deal with a problem peculiar to Netscape browsers
running
> an applet using XMLRPC. It is apparently a known problem that applets
> (we're using JRE 1.3.1 via the plug-in) on most versions of Netscape
> browsers don't send reliable HTTP header information when using an SSL
> connection (it's okay via non-SSL). I was getting "invalid
content-length"
> errors at the Apache server (before the request even reached the servlet
> running in Tomcat). By removing the line that sets the content-length in
> XmlRpcClient.Worker.execute(), the problem was resolved and requests are
> accepted by the Apache server (see below).
>
> URLConnection con = url.openConnection();
> con.setDoInput(true);
> con.setDoOutput(true);
> con.setUseCaches(false);
> con.setAllowUserInteraction(false);
> < con.setRequestProperty("Content-Length",
> < Integer.toString(request.length));
> con.setRequestProperty("Content-Type", "text/xml");
>
> But I'm wondering if this is the best solution, or if anyone else might
> have a more elegant (or reliable?) solution. Any suggestions?
Don't have a suggestion, but have recently learned that this is
against the spec <http://www.xml-rpc.com/spec>.
