I found a kind-of work-arround:

• activate html-include macro
• insert the html-include macro on the page you want the attachment to display
• paste the download link as URL
• for attachments from internal pages, attach &os_authType=basic&os_username=username&os_password=password

This will download the attachment server-side and paste it inside your confluence page. Unfortunately this does not seem to include javascript.

This is sooo easy to fix... Please do.
You can fix it in different ways e.g.
-change the mime type ot be directly displayable in the browser
-Adapt html-include macro to be able to refer to attachments
Extend the View File Macro < preferred way
-....

We have also come across this issue now, and it has been confirmed by a support technician that even if the MIME type of an attachment is set to text/html, confluence serves the file as application/x-download. He also confirmed that this is still the case in the current version 5.1

my suggestion would be to add a "View" link on the attachment page, similar to the Office file types, so the user could click this link to download the html file using text/html mime type instead of enforcing application/x-download.

I just ran across this issue myself and would like to ask for a resolution.

Is there a workaround for this? There must be if this is so old and nothing was done...

http://jira.atlassian.com/browse/CONF-389 just yields a "permission violation" to me... We are also having users complain that when they add HTML attachments it comes in as a download instead of just coming up like other content types. Has anyone figured out a good workaround in the... 3 years since this has been reported???

Can somebody tell me which changes have to done in source to get a inline HTML view?
Or are any other workarounds or plugins around in the meantime?

Rather than adding a preference, which seems it might require several changes, and might be hard to configure on a per-page basis, perhaps the following workarounds would be easier:

0. Provide a way to get a permanent URL that refers directly to an attachment.

1. Provide for /attachment URL segments to be understood by the /display verb.

2. (optionally) add ^^ as the syntax for generating a /display/attachment/... URL instead of a /download/attachment/... URL.

Just doing (0) would allow users to insert an explicit link to the attachment. Doing (1) would allow for this URL to be predictable (a la the %ATTACHURL% mechanism of many Wikis). Doing (2) would make it trivial to insert these links.