HTTP tunneling is often considered a bad idea. There are five major reasons for this:
At its heart, HTTP tunneling involves deliberately circumventing a security mechanism that someone else thought was necessary and worked hard to install. It involves deliberately relaxing the security provisions on a trusted network.
Ordinarily, this isn’t such a big deal. You’re a reasonable person and remote method calls aren’t so big a risk (especially if you use a secure web server to handle the HTTP traffic). However, and this cannot be stressed enough, you should not enable dynamic classloading if your application will use HTTP tunneling. Downloading classes from outside a firewall and executing them inside a firewall constitutes gross negligence. I’d fire anyone who did it.
RMI is already a verbose
protocol; it encodes a lot of information in each
message request. Taking an RMI message and
wrapping it in an HTTP post by inputting the RMI
message as the body of the post and then setting
five or six message headers just adds insult to
injury. Using HTTP tunneling could easily double
bandwidth requirements for many remote interfaces.
In particular, consider the output of
simply prints out the HTTP headers from a request.
HTTP tunneling does not support keeping connections open and reusing them. Unlike JRMP, in which sockets may be reused for dozens of method calls, HTTP ...