[xmlrpcflash-development] Re: [xmlrpcflash - Open Discussion] secure functionality with Flash xmlrpc

[Martin R. <m.r...@uc...>]

On Tuesday, November 26, 2002, at 10:59 PM, Isaac Levy wrote:
>
> Agreed.  There are some shortcomings inherent in the spec.

I think that they could be fixed fairly easily. RFC style 
(http://www.ietf.org/rfc/rfc2119.txt) gives an approriate level of 
precision for spec docs.

The current spec isn't quite at that level of precision.

> As an aside, the reason I like working with xmlrpc (over SOAP, for 
> now), is that it is so simple, and that the shortcomings are usually 
> simple to overcome.  Good for a reductivist development approach.
>
> It did make me interested in the SOAP spec, but this is SUCH a moving 
> target, and so many big hands are in the pot, that I don't see it 
> being practically implemented anywhere yet- (and haven't seen much 
> done with it).

In our case, I was looking at xwt (http://www.xwt.org) as a possible 
user-interface for another project. It uses xmlrpc for comms back to a 
server, much like an xmlrpc flash app.

The simplicity of xmlrpc over SOAP (which I've hardly looked at all, to 
be fair) won us over pretty quickly.

>>> Header requirements
>>
>> I believe that it should actually read something like this (maybe 
>> expanded a little).
>>
>>     Any valid POST request is a valid XML-RPC request, with the 
>> following conditions: Content-length MUST be specified and correct.
>>     Content-type SHOULD be set to "text/html" and User-agent and Host 
>> SHOULD be specified. The URI must be valid.
>>
>>     The URI can be used by the server to route the request to the 
>> XML-RPC service.
>>
>> Why is this better?
>>
>> Content-length is the only "useful" field. Your xml-rpc handler is 
>> going to choke on the payload if its not in the correct format, 
>> regardless of the Content-type header value. Similarly, User-agent 
>> and Host are not required for correct operation. Why make them 
>> mandatory?
>
> Ah, if I have your question right, I have an answer from my 
> experiences-

I figured it might be something like that, but those are historical 
reasons, not proper motivations for the spec (except that where 
possible, the spec should not break backwards compatibility).

> --Now, I use Apache to Proxy Zope and do a lot of server 
> heavy-lifting, so my Flash solution was to use the Apache2 
> Request-Set-Header directive, and create a subdomain for xmlrpc 
> requests.  It simply and reliably injects the header before the POST 
> reaches my app server.

This is exactly my point, kind of. Your container might want to all 
kinds of funky manipulations on the requests headers and URI before 
handing them to xmlrpc to process. xmlrpc should only *require* headers 
that it *actually requires* (although others may be encouraged).

A good (as in easy to work with) xmlrpc server implementation (the 
xmlrpc part, not the container itself) shouldn't *require* the 
Content-type header (or should at least allow it to be optionally 
ignored) because if its been handed a call, that call is almost 
certainly xml, and if it isn't, it will be caught downstream during 
parsing anyway. Content-type: text/xml should be a SHOULD or MAY item, 
rather than a MUST. This would save you having to fiddle with 
Request-Set-Header for a start.

Similarly, irrelevant headers should be silently ignored, and this 
should be explicitly specified in the spec. The container may be using 
these to do all kinds of stuff (e.g. http auth).

Good quality client implementations will allow access to header 
manipulation, and this should be a SHOULD item, and strongly encouraged 
in the spec.

>>> I would LOVE for flash to have the ability to read(and write) header 
>>> infoirmation properly.
>>> Regardless- xmlrpc servers are created to have Fault-Codes returned 
>>> for different values.  This is specified here:
>>> http://www.xmlrpc.com/stories/storyReader7
>>
>> It is pretty poor that it doesn't.
>
> Yep.  MM has decided to hold those keys, but to give a bit of the 
> benefit of the doubt to MM, I'm assuming it also keeps the plugin-size 
> small.

I can't see it adding very much to the binary size. Its just setting a 
string at the end of the day.

> So, in the end, it seems to me that the source of a lot of the 
> problems with flash is an Open/Closed conceptual rift.

Its their right, as a commercial organisation, to restrict customer 
flexibility in order to encourage sales of their premium products, 
although I suspect that they wouldn't lose many customers by opening up 
access to request headers in the XML object.

But its also a good reason to mark implementations which don't support 
access to the functionality of the underlying HTTP protocol as poor 
ones.

It would be nice if the open libraries did this, but if you're using 
XML.sendAndLoad, you might have problems. One option might be to 
provide your own http lib which users can switch to if required.

> Hmm. That's a shame.  Well, it took 3 revision versions of Zope to 
> finally get fault codes in a sensible state- but in the end, it wasn't 
> that painful- and now, I am able to get python tracebacks and server 
> error messages with fault codes.

I don't think I've even seen any ... the jakarta client lib just seems 
to throw client exceptions if there's a problem, although it may be 
using fault codes under the hood (and most problems we've had are http 
level ones ... e.g. 401's).

> It is my understanding, (correct me if I'm wrong), that Jakarta is an 
> application Servlet which was created to work primarily with 
> Tomcat/Apache.

Jakarta (http://jakarta.apache.org) is the Apache Foundation's project 
for server side java. Their products include Tomcat, Ant, Struts, and a 
whole lot more.

> Right- and you can build your flash app to deal with a given error in 
> some sensible manner for the end user as well, or provide some sort of 
> feedback/logging mechanism to the server, etc....

exactly.

    cheers,
              m.