The Flash 9 ExternalInterface page notes this in a comment at the bottom.

Turns out there is a whole bunch of 'special' words that break IE in different contexts, mostly DOM id's that will break IE. Eric Meyer has a better explanation with demos here.

Fail

Everything works great, for instance, and then you export a release build and it doesn't work. Or trouble going from a file:// to http://. Anyway, after sufficient logging, I was well on my way. And then, boom, IE drops the the ball again.

IE, you epic fail

Anyway, after much Parallels-ing and googling, I get an answer. It wasn't giving the object tag an id

classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" .....

Flash OBJECT and EMBED tag syntax

Flash OBJECT and EMBED tag attributes

I was recently trying to implement an upload to Amazon S3, and it wasn't working. I couldn't tell if it was the Flex front end, or the S3 backend, or what, so I decided to Wear my ruby slippers to work, or rather my Rails slippers (so comfy and I just like them so much).

About 15 minutes and 15 lines of code later, I had a rails app running locally which accepted the upload from Flex and logged all the request parameters. I found the Simplest upload that could possibly work in the Rails Cookbook, and a Rails wiki page to that purpose. In the Rails Cookbook, note that you should use params['file'] rather than the oldschool @params['file'].

To get a simple Rails (> 2.0) app for testing the uploads, try this

rails uploader
cd uploader
script/generate controller upload

Paste in some code from the Simplest Upload Possible article above.

class UploadController < ApplicationController
  def save_file
    logger.info(params.insect)

    if request.get?
    render :text => 'Please Upoad file'
    else
      # Use "wb" mode on windows.
      File.open("#{RAILS_ROOT}/public/files/#{Time.now.to_i}.jpg", "w") do |f|
        f.write(params['file'].read)
      end
    render :text => 'Done'
    end
  end
end

Now, in Flex, have your FileReference upload to your server, and make sure to use the right field name.

[ActionScript]
var urlRequest:URLRequest = new URLRequest("http://127.0.0.1:3000/upload/save_file");
urlRequest.method = URLRequestMethod.POST;
file.upload(urlRequest, "file");
[/ActionScript]

Tails your logs, and look for the output. One step closer.

I might try to clean up a simple uploader app and thow it up (blaagh) here. Any interest?

After much googling, Wiresharking, and general debuggation, a co-worker found this Amazon S3 doc, which notes:

Some versions of the Adobe Flash Player do not properly handle HTTP responses that have an empty body. To configure POST to return a response that does not have an empty body, set success_action_status to 201. When set, Amazon S3 returns an XML document with a 201 status code. For information on the content of the XML document, see ???. For information on form fields, see HTML Form Fields.

Interesting. And small; it is a tiny message, almost a footnote, on some Amazon page. I wish Adobe could get their docs together. I particularly like "Some versions" and "???". Anyway, lesson learned, or at least we have something to try.

The S3/Flash interactions need a little massaging

It seems like the OS X Flash runtime (9.0.115.0) requires a non-empty server response from its POST. Amazon S3 conveniently has an additional parameter, success_action_status which can be set to "201" to have S3 respond to the post with a 201 CREATED response code. If you are uploading to Apache or IIS, you could have the same problem. Try to check the header response for your POST, and see it is is a) empty, or b) not a 201.

On S3, you can modify your upload policy to return the correct response. Your policy should look something like this:

{
    'expiration': '2008-12-31T12:00:00.000Z',
    'conditions': [
        {'bucket': 'my_test_bucket'},
        {'key': 'test1.jpg'},
        ['starts-with', '$Filename', ''],
        ['eq', '$success_action_status', '201']
    ]
}

Note that the success_action_status is not an object property, but an [Operator, Operand, Operand] array.

Problem Solved? Not quite: still not uploads.

S3 Upload Example

Someone at AWS posted a helpful Flex -> S3 example, or actually examples. One Flex project creates and signs a policy, and the other uploads a file using the generated policy. And whats more, they both work. Also, took a look at the code to make sure it wasn't sending my AWS key/password off to some email! Ha. I think it was also posted by an AWS employee, so that is reassuring.

#2038 FileIOError

I kept getting a #2038 FileIOError on my mac. Bummer. Taking a closer look at the working AWS example, I saw a funny comment. Not funny roflcopter, but funny smelly bug-fixy.

            /*
             * FileReference.upload likes to send cryptic IOErrors when it doesn't get a status code that it likes.
             * If we already got an error HTTP status code, don't propagate this event since the HTTPStatusEvent
             * event handler dispatches an IOErrorEvent.
             */

As it turns out, I could NOT stop these #2038 FIleIOErrors. They just kept coming. But, as the example code reminded me, if you are getting a successful server response, the file is already up there. Sure enough, the file was there.

So you can pretty much ignore the FileIOError, although you should handle it, and just ignore it if you have a successful HTTP response, something like this:

        private function onIOError(event:IOErrorEvent):void
        {
            if(!recievedSuccessfulHTTPresponse)
            {
                this.dispatchEvent(event);
            }
        }

You get the idea. Ok. Handle but ignore FileIOErrors. Done? Almost. Single uploads work, but I get an "Error #2044: Unhandled IOErrorEvent:. text=Error #2038: File I/O Error" when doing multiple uploads, via a FileReferenceList. Marvelous. This turned out to be even more of a pain. It wasn't anything to do with the server side upload script as my google searches might have me believe.

After brainstorming with a co-worker, we came to a pretty good guess: Garbage Collection. Maybe the FileReference was going out of scope before the IOError could be handled, or some such. PC/OS X differences in the runtime could have different GC implementations. Worth a shot. I changed my event listeners from "weak" to "strong" references. Shahooya. Multiple file upload city.

Other fixes

Make sure you have a publicly accessable crossdomain policy on the server you are uploading to.

Also, S3 scales well but adds extra complexity. You might try uploading to somewhere else, like a simple rails uploader.

Hope that helps. Also, please comment. In fact, today only, every commenter gets a free XBox. You know, its just a little lonely out here in the cloud sometimes.