Client

The proxy isn't very interesting until we create a client that will use it. In particular, we want a Flash client that allows us to demonstrate our ability to grab XML data from anywhere on the Internet, not simply within our own domain.

Transparency of the Proxy

Ideally a proxy is completely transparent to the application. In some situations this is the case; Many corporate environments, for example, use firewalls that function as proxies. These proxies are smarter than ours: They analyze the content and source of messages and actively filter them. They also manage error conditions far more gracefully. And they are invisible to all but the very lowest layers of Internet software. The users of a client-side socket are generally unaware that a proxy sits between them and the remote server with which they are communicating.

As we build a Flash-based client to work with our PHP proxy, we cannot achieve such transparency. Unless we are prepared to do some extravagant rewiring of the Internet, we must address the URL of the proxy and only indirectly the URL we really want. But we can come close to this ideal by wrapping up the proxy communication and hiding it inside a function. A sweet way to do this is to write an extension of the XML.sendAndLoad() method.

Extending the XML Object

Let's write an extension of sendAndLoad() called sendAndLoadRemote(). We wrap the proxy in this new function, which mimics the functionality as well as the interface of the original sendAndLoad() . The difference is that our new function is not restricted by the Macromedia domain perimeter. (And it requires the presence of our new PHP proxy on the server.)

This is a simple but very useful function. We might wish that it were available in all our XML objects. It can be. We add this method to all our XML objects by installing it as an extension of the standard XML object's prototype.

ActionScript

 XML.prototype.sendAndLoadRemote = function ( url, xmlResponse ) {   xmlRequest = new XML("<xml><proxy-target>"+ url +"</proxy-target>"              +"<proxy-request>"+this.toString()+"</proxy-request> </xml>");   xmlRequest.contentType="text/xml";   return xmlRequest.sendAndLoad( "xml-proxy.php", xmlResponse ); } 

The first line in this function composes the message we will send to our proxy. It is a single XML element, as all XML documents must be. But this element can contain two daughter elements.

The required element, <proxy-target>, is a simple URL. It can contain the method prefix ( http :) and the double slash, although our proxy will simply discard everything up to (and including) the double slash. It can include a GET style suffix ( ?someVariable=someValue ) that will be preserved.

The optional element <proxy-request> is an arbitrary XML structure. In fact, it is the con tent of the XML object ( this ) that is performing this method. This element is optional from the point of view of the proxy. (GET requests , for example, must ignore it.) Since there is always a calling XML object, this option will never be undefined, but it will often be empty. This method is frequently called with a new XML object, and in such a case the request ele ment will be empty of real content.

Note also that this line of code is not simply composing a quick and dirty XML string by concatenating the appropriate fragments . We have done so in the past and used the resulting string directly as XML. Here, however, we are using the string as source code. The ActionScript parser is fed this ad hoc XML string and creates a genuine XML object in memory. We will see the importance of this on the third line.

ActionScript tolerates a shortcut we have taken with this code. If the XML object calling it has a prologue (the XML header, rarely seen internally, but always part of a formal validated XML), the prologue is supposed to precede the XML data proper (i.e., the header comes before the document contents). In our code, the prologue is produced properly by XML.toString() but then embedded incorrectly in the XML string, which should not compile. ActionScript assembles the final XML properly.

• Prologue (from a WAP XML file)

XML

 <?xml version="1.0"?><!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"   "http://www.wapforum.org/DTD/wml_1.1.xml"> 

• Malformed string fed to the tolerant ActionScript parser to make xmlRequest

XML

 <xml><proxy-target>http://robots.net/rss/articles.xml</proxy-target>   <proxy-request><?xml version="1.0"?><!DOCTYPE wml PUBLIC "-   //WAPFORUM//DTD WML 1.1//EN"  "http://www.wapforum.org/DTD/   wml_1.1.xml"></proxy-request></xml> 

• Proper XML as corrected by ActionScript and reported by xmlRequest.toString()

XML

 <?xml version="1.0"?><!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"   "http://www.wapforum.org/DTD/wml_1.1.xml"><xml><proxy-target>   http://robots.net/rss/articles.xml</proxy-target></xml> 

The second line ”

ActionScript

 xmlRequest.contentType="text/xml"; 

”merely sets the content type correctly. Some older systems, including perhaps the ones which you are contacting by proxy, ignore (or even mishandle) the XML content type. But it must be set properly here. PHP requires it, and bear in mind that this header is intended only for the PHP proxy.

In the final line ”

ActionScript

 return xmlRequest.sendAndLoad( "xml-proxy.php", xmlResponse ); 

”we wrap this function around the actual ActionScript data exchange method, sendAndLoad() . The necessity of creating a full XML object in the first line should now be clear. sendAndLoad() is a method of the XML object and the only way to upload XML data.

Calling this function from a new XML object with the URL http://bigfun.net/site.xml causes this to be sent to the proxy (whitespace added):

XML

 <xml>   <proxy-target>http://bigfun.net/site.xml</proxy-target>   <proxy-request /> </xml> 

Now we have a function that can be used with any ActionScript. But we need a demonstra tion program. A dramatic demo program is one that will allow us to display files from all over the Internet. To do this, we want to input a very popular XML file type.