Sunday, December 30, 2007

Content-Disposition with Adobe Air / Flex HTMLLoader

It appears that the HTMLLoader in Adobe AIR 1.0 Beta 3 has no way of handling the HTTP Content-Disposition header when set to type 'attachment'.

An example is
Content-Disposition: attachment; filename="fname.ext"

When the Air HTMLLoader encounters an HTTP response with a Content-Disposition similar to the example above, I haven't found a way to retrieve the HTTP response body. This is bad news if you want to create an Air browser that is capable of common Web Browser file-download behavior.

The correct behavior for an HTTP client which receives an HTTP response parameter of this type can be found in RFC 2616, section 19.5.1. It is stated that "If this header is used in a response with the application/octet-stream content-type, the implied suggestion is that the user agent should not display the response, but directly enter a ‘save response as...’ dialog". I suspect that Adobe hasn't had a chance to implement a way for HTMLLoader to notify client code of this situation, or the process for getting the HTTP response body.

I've posted to the Adobe Air forum and filed a Flex bug:
Adobe Air Forum Post
Jira Issue

Thursday, December 6, 2007

Automating Browser Workflow with Adobe Air / Flex

It would be great to be able to automate a set of steps that you take frequently within your web browser, and have the information that you're actually after extracted for you automatically. For example, if I were interested in obtaining my financial transactions automatically from my bank each month, a tool with this functionality could be used to download this information automatically in the background.

I dove into this issue a bit the other day using Adobe Air with Flex. I quickly found myself blocked. I couldn't figure out how to intercept the resultant URLRequest that is generated by a user clicking on a link within a rendered HTML / JavaScript page. For example, Imagine I load an initial web page with a form that has a submit button. I fill in information into the form (in the HTMLControl within my flex UI), and click submit. It appears that there's no way to get read access to the URLRequest that is being sent as a result of clicking the submit button. Further, I would like to be able to intercept that request, possibly modify some of the submission parameters, and send it later with a stand-alone URLLoader.

The closest I came to this information was by overriding HTMLHost.updateLocation(), and with the HTMLControl.locationChange event. The most information I was able to find was the new URL being loaded. Even worse, it appears that in both of these cases, I intercept control after the HTTP request has been sent.

It’s looking more and more like this isn’t possible. If it were, some pretty neat tools could be developed.