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

[Isaac L. <is...@st...>]

Hello Again Martin, All,

Back and rockin' after a thanksgiving hiatus...
Some of the below comments on the Content-Type issue are a bit off 
subject (in lieu of directly working on the current flash lib), but I 
thought this would be a good moment to dive into this issue:


On Wednesday, November 27, 2002, at 05:50 AM, Martin Redington wrote:

>
> 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.

Yep.  Agreed.

> ...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).

Well, I'm not really just drawing from my experiences here, (in 
personally mandating implimentation of the Content-Type header), but it 
comes from fundamental differences in modes of operation, between 
various xmlrpc mechanisms.

I have posted a quick generalized diagram here:
http://xmlrpcflash.sourceforge.net/diagram/xmlrpc_server_types.jpg

It illustrates one main point- that server applications which are 
designed to deal with calls in different contexts, the Content-Type 
header and POST are needed, to distinguish the xmlrpc call, from other 
http calls (i.e. html form POST data, etc...).

It is my understanding that this is how Userland's server software 
distinguishes between incoming http calls (to enable certain actions to 
be taken from both an administrative web browser, and their xmlrpc 
desktop app, [all over http- and over one port]).

Now, for a strict xmlrpc server, it could be set-up to manipulate the 
same back-end data, (i.e. a database, whatever), but then the server 
would need it's own port, [defeating the idea of being able to run 
xmlrpc over port 80, while serving html over port 80 as well]).

>
>> --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.

Well, based on my above explanation, I respectfully step back a bit;
though the Content-Type header is irrelevant when applied to specific 
servers which are meant ONLY for xmlrpc, this does not seem to be 
common practice in the construction of servers, as they are commonly 
designed to serve and use the same sets of data in different 
technological contexts.

Therefore, although it is not always necessary for the client to have 
Content-Type set correctly, it is necessary in order to work with a 
great number of xmlrpc-aware application servers (in the context of 
running all that http over common port 80- or even over https on common 
port 443).


> 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.

Right.

>> 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.

I agree.

>
>> 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.

I agree strongly here too.

> 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.

Well, yes- but defining this at the spec level does make for a bit of 
fragmentation, (as the general objective is that all xmlrpc speaks to 
all xmlrpc).
This will be noted as more documentation for the flash lib is created, 
as this issue must be clearly and simply addressed on the sourceforge 
side of things.

> 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.

How do you mean here?  This sounds interesting(?).


Best,
Isaac



   Isaac Levy
+ Office of Structured Systems
   http://structuredsystems.net