xml-rpc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ar...@cornell.edu
Subject Re: recent patches
Date Fri, 13 Sep 2002 19:24:51 GMT

Well, unfortunately the XML-RPC spec does not provide any way to pass 
contextual info :(  Contrast to the SOAP spec which actually provides an 
"envelope" in which you can stick contextual information.  I don't think 
there is a way to escape this requirement for passing contextual 
information.  For example, consider my real-life case: I have to 
implement Kerberos security for XML-RPC.  What that requires is the 
ability to pass a Kerberos ticket with an XML RPC request.  As you say, I 
can pass that as a parameter, or I can use a context-passing mechanism, 
which is of course *strongly* preferred.  That's all fine and good, and 
let's just suppose XML-RPC had a way to pass this info in the spec, let's 
say through a <meta-info></meta-info> tag.

Now say I want to actually encrypt the XML-RPC request by the Kerberos 
session key, which is obtained through the contextual info I pass.  Now 
you see a catch-22: I cannot encrypt the XML-RPC request if it contains 
the contextual info because the contextual info is needed to decrypt 
the request in the first place!  So the only option is some mechanism 
which passes the contextual information _outside of the spec_.  This is 
an example where despite how well designed the spec is itself, there 
still needs to be a provision by the library designers for scenarios they 
cannot predict...interceptors allows that flexibility.

But I'll take baby steps and be happy if contextual-information-passing at 
all is incorporated :)  I just wanted to explain why I believe "out-of-band" 
contextual information passing is desirable.  I don't see this as "bending" 
the spec any, since it is neither mentioned nor forbidden by the spec...I 
see it as an additional feature of the library.  In the end, inclusion 
will be determined by whether the majority of XML-RPC library users would 
find a feature worth the effort (well, I've already expended the effort 
myself)...it's my opinion this is a useful feature (and looks like it 
could have saved you some work and lots of ugly code on the servers to 
handle sessions) :)


>Subject:  Re: recent patches
>From:     Ryan Hoegg <rhoegg@isisnetworks.net>
>Date:     2002-09-13 18:17:13
>Hi.  My service provider has had an XML-RPC API to their application for 
>over a year now, and they have had to solve the same problem.  They want 
>to be able to identify 1) the business client that is accessing the app, 
>2) the username/password credentials of the user within this client, 3) 
>session ID, and 4) the version of the API the client is requesting.  In 
>addition, they support some "more meta" information (is that a word? :)) 
>such as HTTP compression settings, SSL, etc.
>Their solution was to do exactly what you mentioned: requiring this 
>information as a struct in each XML-RPC request.  They also use a cookie 
>(redundantly) to set the session ID.
>The problem with trying to embed "meta-information" is that either
>A) It has to be a part of the XML-RPC request, as above, or
>B) it is not a part of the XML-RPC request.  This could be cookies, or 
>other transport protocol features such as POST parameters or some such.
>My objection to B is that it is necessarily not covered in the XML-RPC 
>spec, causing an interoperability problem.  There are stable software 
>libraries out there right now doing MIME-RPC, for instance, using the 
>XML-RPC spec but switching out HTTP for MIME.  The more implementations 
>decide to bend the spec in different ways, the less useful the spec 
>Your example of the client operating system is a perfect example.  IMHO 
>the way to do it is to submit an XML-RPC request defined by the 
>application to authenticate and get a session ID.  This initial request 
>can contain such information, and future requests can contain the 
>session ID.
>Ryan Hoegg
>ISIS Networks

View raw message