As some of you may already know, I run and maintain a few of my own products, the most popular of which being Scribblar which pushes hundreds of sessions every day.

Recently I started getting reports from users that the main page which hosts the applications' main SWF file was not loading properly, or it would work in one browser but not another. Within the handful of reports I had, Google Chrome appeared to be the browser that posed most of the issues - this seemed odd as Chrome effectively has Flash Player built-in and always auto-updates to the latest release version which is why I recommend it as the preferred browser to anyone who asks.

My first look was towards SWFObject - I figured that maybe something in Chrome had changed and broken the Flash Player detection. A common trap that some developers fall into is to check for specific Flash Player versions, for example only allowing access to Player 11 or below, which then locks users out once Player 11.5 (or similar) is released. But this wasn't the issue here.

After much more digging and more back-and-forth emails with some users I noticed a very odd behaviour when trying to access my SWF directly (without an HTML wrapper) in Chrome. This image shows the request in the Chrome Debugger.
Chrome Debug Output
Notice how the shows as 'canceled', and that the content type is coming up as the generic binary/octet-stream? Clearly this pointed towards Chrome not being able to deal with a wrongly set MIME type correctly, whereas other browser may have handled this is a more flexible way.

My files are served via Amazon S3, and the MIME type is usually set during upload and forms part of the file's metadata. My FTP client of choice is Transmit, and after some digging I spotted the 'Cloud' panel in Transmit's preferences.

Here you can specify a particular MIME type to go along with a file extension. For SWF this would be application/x-shockwave-flash (but while you are there you may as well set it up for other file types such as CSS).

After setting these Transmit preferences, all subsequent SWF uploads had the correct MIME type set and hitting the SWF directly in Chrome now gave the desired results. If you need to update the MIME type post-upload then have a look at tools such as BucketExplorer or S3 Browser (Windows only).

It now makes sense why my file showed as MIME type binary/octet-stream: this is the default MIME type used by S3 when no other MIME type is specified during the PUT operation into S3.
This issue took me a while to track down and I hope the information above helps someone.