It seems that it is not possible to replicate standard
browser behavior with Browser Attachments. If I go to any website
that allows the downloading of a file to disk, an Air application
can't be created such that it can save that HTTP attachment that
was given. This makes it impossible to create a fully functional
browser with Air.
The problem is, HTMLLoader in Adobe AIR 1.0 does not handle
the HTTP Content-Disposition response headers set to type
'attachment'. It simply ignores this header. This is bad, because
many sites on the web rely on user-agents handling this header
appropriately in order to initiate a download of a file to an
end-user's local disk.
An example is
Content-Disposition: attachment; filename="fname.ext"
This HTTP response header says to the user agent, 'Don't
render this response as HTML; instead write the response to a file
on the user's disk called fname.ext'.
When the Air HTMLLoader encounters an HTTP response with a
Content-Disposition similar to the example above, nothing is
re-rendered (which is the correct behavior), there is no way to
detect that the attachment Content-disposition header has been
served (bad), and there is no way to obtain the attachment itself
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.
Has anyone encountered a work-around? Does anyone know of
plans in place to correct this bug?