Dynamic Flash

In attempting to upgrade the AirShows application to use the new AIR 1.5 runtime, I tried to simply change the target SDK to Flex 3.2 in the project settings. However, this was giving me all sorts of strange errors, from not launching to displaying the following error dialog when trying to launch the application in debug mode:

On a hunch, I checked the application configuration file AirShows-app.xml file and noticed that it uses the following namespace declaration:

<application xmlns="http://ns.adobe.com/air/application/1.0">

Since the Flex 3.2 SDK actually expects to be building AIR 1.5 applications, I had a feeling that this was the root cause of my problem. A quick change in the namespace to the following solved my problem:

<application xmlns="http://ns.adobe.com/air/application/1.5">

Thankfully I didn’t waste a whole lot of time trying to figure this out, but I do wish Adobe had provided slightly more useful error messages.

I find it shocking that the Flash Player still lacks the ability to properly interact with RESTful web services. I keep running into this issue, and every time I scour the Internet hoping that someone, somewhere has found a solution. Every time I return disappointed, hating the Flash Player just a little bit more.

REST stands for REpresentational State Transfer, and describes a technique to organise a web service into resources that can be uniquely identified by a URI. The actions that can be performed on that resource map directly to the standard HTTP methods: GET, POST, PUT, DELETE, HEAD and OPTIONS. With properly organised resources it’s possible to do virtually everything you can do with an RPC-style web service with REST. The benefit of REST is that it goes with the grain of the web, not against it.

The problem with the Flash Player is that the URLRequest class, which is the basis for all HTTP requests, only supports GET and POST operations¹. This is due to a limitation in the NPAPI pseudo-standard used by non-IE browsers that only exposes the ability to make GET and POST requests. Unless NPAPI is updated to allow other HTTP methods, and browser vendors and plugin authors update their implementations to match that new API, we need to find other ways of interacting with RESTful web services.

Now, If you’re lucky, the web service you’re trying to interact with will support some way of overriding the request method, such as a X-HTTP-Method-Override header. If this is the case, you can use the requestHeaders property of your URLRequest object to set the appropriate method:

// Create request object with appropriate resource URL
var req:URLRequest = new URLRequest( 'http://rest.example.com/v1/book/1234' );
 
// Use POST because DELETE is non-idempotent
req.method = URLRequestMethod.POST;
 
// Specify DELETE method in X-HTTP-Method-Override header
req.requestHeaders = [ new URLRequestHeader( 'X-HTTP-Method-Override', 'DELETE') ];

If your web service isn’t quite so forgiving, the only option you have is to use the ExternalInferface class and some JavaScript magic to make requests on behalf of your Flash project and send the response back. It’s an ugly hack, but a developer’s gotta do what a developer’s gotta do. If you’re interested in this workaround, leave a comment and I’ll knock up a simple example.

For what it’s worth, Silverlight fares no better in this regard. This is not surprising since Microsoft are stuck with the same browser plug-in APIs as Adobe, but that doesn’t make it any less annoying for developers on both sides of the fence.

At work we’re working on an application that makes heavy use of the FileReference.upload() method to upload files to the server. We recently had a change request to add some custom HTTP headers to the upload request, which I didn’t think would be a problem. I was wrong.

When using the FileReference.upload() method to upload a file to a server, you can specify additional variables to be sent along with that upload request by means of a URLRequest object like so:

// Create new request object and point it at the right URL
var request:URLRequest = new URLRequest();
request.url = "/upload.php";
 
// Specify additional variables to be sent with request as POST data
request.method = URLRequestMethod.POST;
request.data = new URLVariables();
request.data.foo = "bar";
 
// Upload file using data from request object
fileRef.upload(request);

Since you can send custom headers using the URLRequest object’s requestHeaders property, I should have been able to specify custom headers for my file upload request fairly easily:

// Create new request object and point it at the right URL
var request:URLRequest = new URLRequest();
request.url = "/upload.php";
 
// Specify additional variables to be sent with request as POST data
request.method = URLRequestMethod.POST;
request.data = new URLVariables();
request.data.foo = "bar";
 
// Specify additional headers to be sent with request
var header:URLRequestHeader = new URLRequestHeader('X-Test-Header', 'Hello');
request.requestHeaders.push(header);
 
// Upload file using data from request object
fileRef.upload(request);

Sadly, the above code doesn’t work. I checked the raw request and response using Charles and the custom X-Test-Header I was trying to send just wasn’t coming through. I tried a number of different variations of the same code, all with the same result.

The problem, I have just discovered, is that there are a number of restrictions placed on the URLRequest object when used in conjunction with the FileReference methods. One of these restrictions is that the requestHeaders property is completely ignored when using the FileReference.upload() method, so it’s impossible to send custom HTTP headers along with a file upload.

To be completely fair to Adobe, this and the other restrictions are stated quite clearly in the documentation for the URLRequest object:

The FileReference.upload() and FileReference.download() methods do not support the URLRequest.requestHeaders parameter.

Since I can’t see any security or technical reason why the URLRequest object should be restricted in this way, I’m off to file a bug with Adobe to see if we can get this addressed in a future version of the Flash Player.

Lesson learned: RTFM.