This problem started a few weeks ago.

Whenever I navigate to any page at http://clhs.lisp.se — for example this one: http://clhs.lisp.se/Body/m_w_open.htm — my browser doesn't display the page normally, but instead attempts to download the page as an HTML file.

This happens in Chrome, Firefox, Brave, Vivaldi and Opera; but not in Internet Explorer or Edge. It used to work fine in all browsers.

Why does it happen, and how can I make it work normally? Using IE or Edge is not an option.


3 Answers 3


There is something wrong with the way that website and/or web sever is delivering web pages.

This is not a problem on your end but rather something odd on the server side; with either the website itself or the server delivering web content.

Instead of delivering content with headers that indicate text/html it is delivering content as application/octet-stream which a web browser will interpret as being binary data that should then be handled as a file download. Look at the output of this Curl command:

curl -ILk http://clhs.lisp.se/Body/m_w_open.htm
HTTP/1.1 200 OK
Content-Type: application/octet-stream
Accept-Ranges: bytes
Content-Length: 8896
Date: Sat, 21 Sep 2019 18:41:10 GMT
Server: lighttpd/1.4.45

I’m pretty sure you can’t fix that on the client side unless there is some kind of plugin — for Firefox or Chrome for example — that will allow you to force specific headers for a we request like this.

That said, the core content of that site is available elsewhere on the Internet on sites that are properly configured and working as expected.

Past that, if you simply want to read the content on that site — rather than debug the issue on that site itself — you can access the same content at the following other sites as per dave_thompson_085’s comment to the question:

And as per Dave’s comment, that second MIT link should be authoritative since, “IMHO the proper home; I knew Kent at the time he worked there.”

  • 15
    @SodAlmighty - Contact with whoever manages the website and inform them of the problem. There isn't anything you can do. The fact IE and Edge works is a fluke.
    – Ramhound
    Sep 21, 2019 at 18:53
  • 23
    @SodAlmighty, the fact that IE and Edge work fine with it is a symptom of why IE and Edge are so incredibly easy for attackers to break: the browsers try to guess what behavior will provide the best experience for the user, and someone who understands the logic being used can trick the browser into making incorrect decisions.
    – Mark
    Sep 22, 2019 at 3:07
  • 26
    @ComFreek Imagine a forum that allows people to upload arbitrary files, and other people to download them. They might decide to only serve them via "safe" content-types, e.g. images, and provide everything else as application/octet-stream, so well-behaved browsers just download them. Edge and IE however apparently would treat these files as HTML files and execute inline JavaScript. If there are no additional restrictions implemented in IE/Edge, this is a glaring security hole leading to XSS.
    – Yogu
    Sep 22, 2019 at 11:23
  • 5
    See also the X-Content-Type-Options: nosniff header IE introduced to mitigate the security risk they introduced.
    – Mormegil
    Sep 23, 2019 at 8:02
  • 4
    @ComFreek That particular situation should be handled by using a content-disposition to always download the files, rather than display them. application/octet-stream is not a replacement for the content-disposition, and shouldn't be used as one.
    – trlkly
    Sep 23, 2019 at 13:43

This funny website return for your page an answer with the following headers:

HTTP/1.1 200 OK
Content-Type: application/octet-stream
Accept-Ranges: bytes
Content-Length: 8896
Date: Sat, 21 Sep 2019 18:44:55 GMT
Server: lighttpd/1.4.45

The problem here is the Content-Type field, described as:


some other kind of data, typically either uninterpreted binary data or information to be processed by a mail-based application. The primary subtype, "octet-stream", is to be used in the case of uninterpreted binary data, in which case the simplest recommended action is to offer to write the information into a file for the user.

A binary file cannot be displayed by the browser. As the Content-Type value of "application/octet-stream" defines the return answer as a binary file, a browser that obeys the standard has no other possible action than to download the file.

IE and Edge were never that good at following the standards, which is why Microsoft is currently ditching both.

  • someone should send a bugreport to the IE and Edge teams, this is a bug in their browsers. interpreting Content-Type: application/octet-stream as Content-Type: text/html is definitely a bug
    – hanshenrik
    Sep 24, 2019 at 9:48
  • @hanshenrik It was supposed to be a feature: en.wikipedia.org/wiki/Content_sniffing
    – phk
    Sep 24, 2019 at 14:01
  • @hanshenrik: Such a bug-report is useless. Microsoft is currently ditching both in favor of a Chromium-based version.
    – harrymc
    Sep 24, 2019 at 14:16
  • MIME sniffing was, and still is, used by some web browsers, including notably Microsoft's Internet Explorer, in an attempt to help web sites which do not correctly signal the MIME type of web content display. However, doing this opens up a serious security vulnerability, in which, by confusing the MIME sniffing algorithm, the browser can be manipulated into interpreting data in a way that allows an attacker to carry out operations that are not expected by either the site operator or user, such as cross-site scripting. -- brought to you by Microsoft, good job guys
    – hanshenrik
    Sep 24, 2019 at 15:04

You can try ModHeader. After install you visit the root of the site, click on the extension icon, then on the plus sign, response header and type Content-Type. Happy browsing of that site.

You can use profiles inside the extension, to switch only when needed. If you create a profile without any rules, the icon will show as inactive, that would be the profile for the rest of the internet.

I tested it and it works, but be careful, there is no source code I can see and to modify headers you need full permissions on all pages. You can also enable/disable it from Firefox add-on manager, as needed. More info can be found here.

  • Thank you. However, I have already tried ModHeader in Chrome. I configured it as best I could, yet it did nothing. Either I was using it wrong, or it's broken. Sep 23, 2019 at 0:02
  • Or it doesn't work with Chrome. I used it with Firefox and it worked perfectly. And there is not much to do, as outlined above. Just +, write response-header and type Content-type. I though I had to add something else, like a new value, I don't know. It is almost too simple. Add the rule and that's it. Sep 23, 2019 at 0:07
  • 1
    For any Firefox (or Chrome) extension, the source code is inherently available. The extensions are JavaScript/HTML/CSS which are in downloaded in compressed archives. Any time you install one you always can get the source code. The code might be obfuscated, but you can still inspect it. The only exception to this is if the extension requires you to download a separate executable which must go through a normal application installation process (i.e. not as just a browser extension). If that is the case, then the extension will be asking for the nativeMessaging permission.
    – Makyen
    Sep 23, 2019 at 1:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .