Encrypted Paylod / SSL Possibility

[Mike Boyers <mb...@yahoo.com>]

Hi,

I'm new to this list and XMLRPC.  It's taking me some time to fully digest XMLRPC 3 and how everything fits together, and I figured it's time to swallow my pride and see if I can get a nudge in the best direction.

My client will exclusively be an XmlRpcClient object.  For the server side, it's kind of two-pronged.  In production, I plan on using Apache/Tomcat (so I'll write some servlets that extend XmlRpcServlet and the needed handlers as well, then just set up web.xml to know where the servlets are).  I also need to be able to have a stand-alone server for testing, and for that, ServletWebServer should work perfectly.

So far so good with that aspect, in fact, I've written some prototype code, and it all seems to work just fine.

The area I'm stuck with has to do with data encryption.  All of the payload (but not necessarily the HTTP headers themselves) need to be encrypted in a way that they can't be decrypted.  I've messed around with SSL, but was hoping to be able to do something simpler.  I've assumed (but I could be wrong) that a simpler approach would be to avoid SSL/cert/key pain and just encrypt at the proper point during transmission and decrypt at the proper point during receiving (possibly using a shared key since I control both sides).  But in looking at the javadoc, it's not immediately obvious to me where I'd put such code or what I'd need to extend.

Can someone steer me in the right direction?  I'm not opposed to SSL at this point, I just want to find the simplest but proper way to proceed.

Thanks,
Mike Boyers


      

Re: XML-RPC and File Transfer

[Jochen Wiedmann <jo...@gmail.com>]

On Wed, Jul 16, 2008 at 9:19 PM, Mike Boyers <mb...@yahoo.com> wrote:

> I also thought of the possibility of pulling the contents of a file into a large byte[] and sending that.  This might work, but I could I potentially run into encoding issues?  And I'm also wondering if it even makes sense to try to transfer a large amount of data via this mechanism.  Would it be unreliable to do so or prone to errors?  Would the underlying HTTP transferring mechanism chunk the large data up and send it in pieces?

No, a byte[] is basically the right way to go. On the client side you
may as well use an InputStream (for example to an open file), if I
remember right.

Jochen


-- 
Look, that's why there's rules, understand? So that you think before
you break 'em.

 -- (Terry Pratchett, Thief of Time)

XML-RPC and File Transfer

[Mike Boyers <mb...@yahoo.com>]

I may be way off base with this one, and I don't mind people telling me I am if that is indeed the case.

I have an XMLRPC client and server that supports various transactions.  I'd like to add the ability for the client to upload a file to the server.

In looking at the "extended types" that ws-xmlrpc supports, I noticed the Serializable was there, and since a File is serializable, I thought I'd give that a try.  I got the transaction set up, but this appears to only transfer the File object itself, and not the contents of the file, which is what I'm interested in.  I've been looking around but don't see any equivalently Serializable implementing Object for the file contents.

I also thought of the possibility of pulling the contents of a file into a large byte[] and sending that.  This might work, but I could I potentially run into encoding issues?  And I'm also wondering if it even makes sense to try to transfer a large amount of data via this mechanism.  Would it be unreliable to do so or prone to errors?  Would the underlying HTTP transferring mechanism chunk the large data up and send it in pieces?

Again, if I need straightened out here, please don't hesitate.  In the end I'd simply like to be able to have the client transfer a file to the server, and I'm certainly open to suggestions.

Thanks,
Mike