0 Replies Latest reply on Mar 7, 2008 11:19 AM by nvihinen

    HTMLLoader Breaks HTTP Attachments

    nvihinen
      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 (worse).

      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?