XML-RPC and http

[Mark Baker]

One last attempt ...

Pretend you're a packet sniffer that knows about HTTP and XML-RPC, and
you've found a TCP connection over which HTTP is being used.  What
information can you extract?

If that HTTP stream is used for XML-RPC, you can figure out that a
client is trying to invoke the method "fooBarBaz()".  Then later you
notice a "fooBarBazResponse" coming back.  You don't have a clue what is
going on, except that some interaction just happened between two
machines.  You don't even know if the interaction was successful or not
because XML-RPC faults use a 200 response code.

If you're doing HTTP, you know a *LOT* more.  You know that if you see a
client trying to "GET" a resource called "/myGoat", that the client is
asking for a representation of that resource.  You don't know what the
resource is of course, but you do know that the client isn't trying to
change the state of that resource as it would be with a PUT or POST
(because GET is safe, or at least if it isn't, it's the server's
responsibility).  You can also look at the response code and know if,
and why, the request succeeded or failed.

If you saw the client doing a PUT on /myGoat, you'd know that the client
was asking the server to accept the enclosed body as replacement content
for that resource.  You'd know if it worked or not, and you'd also know
that the state of the server changed if it did work.  For a POST
request, you'd know that the client was attempting to insert the
enclosed body into a container (thereby changing its state), and since
you know the difference between PUT and POST, you know the difference
between those two interactions.  You'd once again know whether this
succeeded or not, and why.

This is pure goodness for so many reasons, not the least of which is
that because I know what's going on during an HTTP interaction, it's
easy to secure (i.e. the "sniffer" could be a firewall).  Not so with
RPC.

MB