I created a "widget" for the sample app that allows uploading a file to the storage service as well as a widget that provides links to the files in a directory on the storage service.

Beginnings 

This began using a custom proxy that used the storage service client methods for talking to the storage service. This was a problem because errors were getting hidden behind the client code. This means the JavaScript would have to depend on an API above the storage service client. This was no good, so I made a slightly simpler call in the storage service client code that returned a traditional ruby http/net response and let the proxy return the values directly to the JavaScript.

The idea was that the widget should be written to handle the service API directly. There are ways to get around XSS security issues with iframes and including script tags (http://developer.yahoo.com/javascript/ provides a great example of this functionality). With that in mind, the first steps were to use a proxy and use the service interface directly. Without the service providing the supported script inclusion hooks, it would not be possible to work around security issues.

Simple Proxy 

With the basic functionality working in terms of JavaScript and a custom proxy, the next step was to create a pass through proxy that simply forwards all requests to the service. This was done as a simple rails controller.

There were some issues to consider. First, all the headers in the request and response did not already apply. Some of the headers relate to the HTTP version used by server. The canonical example of this is the transfer encoding header which is only used by HTTP 1.1 servers and becomes irrelevant in our proxy situation since the response must be finished before sending it back to the client. With that said, other headers and patterns became more helpful. The best example is the content type and multipart form encoding becomes handled by the browser instead of the storage service client. This handles specifying the start/end strings, which seems safer to handle via the browser.

The first tests of the proxy were to try GETs. This worked flawlessly and did not seem to have any issues outside the header manipulation mentioned above. This did require adding a Base64 encoding/decoding library in JavaScript. This did not have any oddities and worked as expected. The next step was handling the POST and PUT methods. This was tested via cURL using the PubSub service. Again, this worked correctly. Lastly the upload test was required.

The uploading was potentially more difficult because the response body needed to be sent along side the correct content type header so the boundaries in the body could be handled. This ended up working correctly, but some issues did arise when the JavaScript did not get a proper directory name or generally if the URL was not correct. This was dangerous because it uploaded properly, but the storage service recorded obviously garbled characters, which makes me wonder if there was an encoding or binary aspect that got in the way. In theory, the value should have been "undefined" as the string, but it was not. 

With the URLs correct and the proxy effectively working, attention turned to the JavaScript to only use the proxy. This was relatively simple and worked as expected.

Current Status 

The first issue that should be addressed is the upload widget response after an upload. The JavaScript has to read the content body of the target iframe to  see if the upload was successful. Then it makes requests to the storage service (via the proxy) to see when it was uploaded to S3. Using the iframe's onload handler has proved to be somewhat unreliable in that it calls earlier than expected. When the target iframe is submitted to, the onload handler is called as well as when the actual page loads in the iframe. I've just begun looking at these issues and it should be very fixable. 

The other issue that should be considered is how provisioning and working with URLs should function. I am doing simple string concats most of the time with the URLs for the respective services. This is OK, but it would be much better, assuming many different services, if the provision service was involved as well as having a consistent set of URL functions (urljoin, urlsplit, urlparse, urlconcat, etc.). These are not critical, but it would be helpful in making sure URLs are constructed properly.

References

Describes XSS attacks - http://ha.ckers.org/xss.html

Yahoo! JavaScript Dev Services - http://developer.yahoo.com/javascript/ 

PPK's discussion on accessing iframes in JavaScript - http://www.quirksmode.org/js/iframe.html 

Remote Scripting with iFrames - http://developer.apple.com/internet/webcontent/iframe.html 

More Remote Scripting - http://www.oreillynet.com/pub/a/javascript/2002/02/08/iframe.html