Give apache access to your Documents folder, so you can view your documents in a browser.

Why?

Working with web technologies, you can't (or shouldn't) avoid HTML, PHP and JavaScript. Apple provides the default webserver serving files from /Library/WebServer/Documents, and your user vhost under ~/Sites, but I don't find either very convenient. I keep all of the projects under ~/Documents, and I want to be able to view those files in a browser as well.

Some of this could be done through a browser over file://, but I find it easier to set it up this way. Additionally, when developing Flash/Flex apps, the security sandbox model can necessitate using HTTP.

How?

First, create a virtual host file with the configuration details at /private/etc/apache2/extra/documents_vhost.conf. Replace USERNAME with your username. I chose port 1234, because it is easy to remember, but you can replace that with a port of your choosing.

<VirtualHost 127.0.0.1:1234>
    DocumentRoot "/Users/USERNAME/Documents"
    ServerName 127.0.0.1
	<Directory "/Users/USERNAME/Documents">
	    Options Indexes FollowSymLinks MultiViews
	    AllowOverride All
	    Order allow,deny
	    Allow from all
	</Directory>
</VirtualHost>

Edit the main apache configuration file, /private/etc/apache2/httpd.conf. Add the following to the bottom.

# Tell apache to listen to requests on this port
Listen 1234
# Include the vhost details
Include /private/etc/apache2/extra/documents_vhost.conf

Lastly, you have to change the permissions of your Documents folder so that it has read and execute permissions, required by Apache to read from it.

chmod 711 ~/Documents

Restart apache

sudo /usr/sbin/apachectl graceful

and visit your Documents folder in your browser at http://127.0.0.1:1234/.

Or, at least, its great until you install it and it doesn't work for a... well it just doesn't work, something about "PROPFIND Server certificate verification failed: issuer is not trusted". Ok, granted I didn't update the self-signed SSL in a year, but its perfectly secure, and I'm not going to pay for this.

This little trick will get you going:

nick$ svn info https://my.repo.com/path_to_repo
Error validating server certificate for 'https://my.repo.com:443':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: my.repo.com
 - Valid: from Thu, 07 May 2009 08:23:36 GMT until Wed, 01 Feb 2012 08:23:36 GMT
 - Issuer: dev, Somebody
 - Fingerprint: 7d:ac:37:52:fe:e9:3f:df:c7:1f:b4:cd:5d:d6:58:0c:29:62:92:4c
(R)eject, accept (t)emporarily or accept (p)ermanently? p

That helps, but also run that for root, which I think is what SCPlugin is using at some level:

nick$ sudo svn info https://my.repo.com/path_to_repo

Firstly, the ability to add arguments was added somewhere along the line, so you might as well make sure you have a recent version of Rake:

nicks-computer:~ nick$ sudo gem install rake
Password:
Successfully installed rake-0.8.3
1 gem installed
Installing ri documentation for rake-0.8.3...
Installing RDoc documentation for rake-0.8.3...

Great. Now, lets dig in to an example rake file. You can put this in a file name 'Rakefile' anywhere you like, or in RAILS_ROOT/lib/tasks/some_file.rake if you are rails-ish.

desc "An example task that uses a single argument"
task :example_with_argument, :arg1 do |t, args|
  puts "Running 'example_with_argument' with '#{args.arg1}' as the argument"
end

desc "An example task that uses multiple arguments"
task :example_with_multiple_arguments, :arg1, :arg2 do |t, args|
  puts "Running 'example_with_argument' with '#{args.arg1}' and '#{args.arg2}' as the arguments"
end

desc "An example task that uses multiple arguments, and has defaults"
task :example_with_multiple_arguments_and_defaults, :arg1, :arg2 do |t, args|
  args.with_defaults(:arg1 => 'default_arg1', :arg2 => 'default_arg2')
  puts "Running 'example_with_argument' with '#{args.arg1}' and '#{args.arg2}' as the arguments"
end

Now, for how to run them. Without specifying arguments, the defaults (or an empty string if no defaults are specified) will be used:

nicks-computer:~ nick$ rake example_with_multiple_arguments_and_defaults
(in /Users/nick)
Running 'example_with_argument' with 'default_arg1' and 'default_arg2' as the arguments

nicks-computer:~ nick$ rake example_with_multiple_arguments_and_defaults[myarg1, myarg2]
(in /Users/nick)
Running 'example_with_argument' with 'myarg1' and 'myarg2' as the arguments

TaDa!

UPDATE:

Rake a a great tool, and widely used, but there are some new tools that surpass rake in some areas. For example check out Thor and how OpsCode uses it with their Knife tool.

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.