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?