How to deliver a piece of HTML code as plaintext to browsers

Problem: We have HTML source code and want to deliver it to the user as plaintext. It should not be interpreted as HTML! (e.g. containing <script> tags and such).
Also it should be possible to save the link as a file, so the solution to deliver it as HTML and just escape everything is not usable. Typical use case: web forum or bugticket system where code or HTML samples can be downloaded so you don't have to copy&paste to save some sample.
The purpose of this page is to show that it can be dangerous to just deliver plaintext with untrusted content, and to show how different browsers/versions react.

Solution: There are several possibilities to influence what the browser does.

• Content-Type: text/plain
  is the most sensible one to tell the browser that it will receive just plain text and that it should just display it without rendering it as HTML. However, Internet Explorer works different and tries to be "clever" - if the content "looks like" a HTML page, it renders it.
  Works for most browsers, but not IE < 9.
• Link-Suffix:
  An additional possibility is to give the browser an appropriate filename, so that if the user sees the plaintext in the browser and they want to save it, the default filename will be the given one. That can be done by just changing the link, e.g. from /script.pl?bla to /script.pl/file.txt?bla. This works depending on how the link normally looks and how the Location is configured in your webserver. The script.pl will be called like before, just with /file.txt in the environment variable PATH_INFO. This solution is also nice because the link already looks like "file.txt" to the user.
  Works for most browsers, but not IE < 9
• Content-Disposition:
  Alternatively you can set the Content-Disposition-header to Content-Disposition: inline; filename=file.txt to tell the browser to suggest file.txt as the filename.
  Works for most browsers, but not IE < 9
• Since Internet Explorer ignores text/plain in any of these cases, the only solution left is to force the browser to do a download instead of displaying the text directly.
  But setting Content-Type: application/octet-stream does not force all browsers to do a download, and you can see in the table below how different the various browsers react.
• X-Content-Type-Options: nosniff
  It was mentioned that IE supports X-Content-Type-Options: nosniff since version 8. So if you don't care about earlier versions, you can use this, and as long as you want to support older versions also, you could check the useragent header and decide what to do. Depends on if you want to keep things really simple or implement the most comfortable solution for each browser.
• Only the combination of Content-Type: text/plain and Content-Disposition: attachment; filename=file.txt works for all tested browsers.
  This forces a download instead of displaying directly, but in most browsers you can still choose to display it directly in the download dialogue, so this solution is comfortable enough for the most cases.

Conclusion:
The "correct" solution (this is also how I understand the specs) would be to set text/plain and give a filename by adding file.txt to the link or putting it into the Content-Disposition.
If you want to be safe and support IE you should switch to forcing a download (if possible, by checking the User-Agent for IE and only switch to download in this case).

Links:

• IE content-type logic
  More or less serious suggestions on this page:
  • Create a new content-type text/plain-no-really ;-)
  • New header X-IE-Follow-Standards: true

2011-02-23 - added hint about X-Content-Type-Options header, described problem more detailed
2011-08-19 - added Opera 11.50 Linux, FF 5.0 Linux and IE 9 Win7

The tests were run bei several diligent helpers (thanks to all), discussed in the (german) perl forum HTML als plaintext