I’ve seen this happen a few times before, and I’m not sure why, but now there’s an example over in this thread. There’s a link to a file of a type that Firefox understands, in this case .JPG . Ordinarily, when you click on a link to a file of that sort, the web browser just displays that file. By contrast, when you click on a link to a file of a type that Firefox doesn’t know how to handle itself, you get a prompt to download it, and possibly to open it in some other application.
Here, though, when you click on the link, Firefox prompts me (and others in that thread) to download it, instead of just displaying it. What’s causing this, and is it something that we should be concerned about?
When your browser and the server talk to each other, there’s headers that tell the browser what kind of file it’s serving up.
Some web site people don’t set this up right. So the header doesn’t really match the content. Stuff like an image/script whatever being shown as something to download rather than display are a symptom of this.
This is especially true of embedded content since the web site people didn’t expect people to access a part of the content rather than the whole page it’s contained in.
When your browser requests something (for example an image) from a web server, the response includes some extra information called “headers”. One of those headers is called “Content-Type”; it describes the format of the response, and the browser uses that to decide how to handle it. In the case of a JPEG image, the server should send the header “Content-Type: image/jpeg”, and then Firefox would know that it is a JPEG image and display it as such. However, for some reason, for this image the server is sending “Content-Type: application/octet-stream”. That’s effectively its way of saying “this is generic, unspecified data”, and so Firefox falls back to the default way of handling unknown files, which is to save them to disk.
This. Firefox doesn’t even recognize file extensions, last I heard, which is ungodly annoying when you handle files that don’t have an associated header type (e.g. .rar).
It’s called a MIME type. MIME is an acronym for Multipurpose Internet Mail Extensions. As the name suggests, it was originally developed to facilitate transfer of non-text or non-ASCII content through email. It’s still used as such in modern email readers; if you’ve ever received an email with *bold or italic formatting, PDF or video attachments and the like, all transparently rendered in your message, you can thank MIME for that.
On sane operating systems, “filename extension” is just the last few characters of the filename and have no meta significance. (“Sane operating systems” means those with a Unix background: Linux, BSD variants, MacOS, etc. “The part after the period” is a DOS throwback (originally aping DEC VMS operating systems), so only means something in Windows variants.)
What this means for a browser is this: if the MIME-type is wrong or unhelpful, the “file type extension” is only available as a clue from the OS in Windows-based OSs. For non-Windows OSs, I suspect the Content-Type has to be authoritatively correct for things to work right; if the browser detects a mismatch between the HTTP headers an the actual byte stream, it probably falls back to downloading rather than trying to process it and doing something potentially bad.
It’s a server misconfiguration as noted in post 5. The server is sending the wrong content-type. It will happen in most browsers, including Chrome and Firefox for Windows, although I tried it in IE for Windows and it loads as an image there. IE probably pays more attention to the file extension if it doesn’t know what to do with the content type.
gnoitall, your information about OSX is rather out of date. Current versions of OSX do use the portion of the filename after the last period, if any, to determine what to do with a file. And it’s been that way for, I’m pretty sure, over a decade.
TIL that the OS X UI, based on NeXTSTEP, does use filename extension as a file-type control. (The kernel probably doesn’t, but that doesn’t matter because no one directly uses the kernel.) Live and learn.
But in the specifics of the OP case, it’s down to the browser’s handling of application/octet-stream being overridden by filename extension (in Internet Explorer) or not (in Firefox, at least in OS X, and in other OSs as well – confirmed for Firefox in Android).
The webserver is misconfigured and technically Firefox is doing the right thing.
I’m honestly surprised this is still an issue. Filetype sniffing has been included in browsers for years. When reading the contents of an inline image, every browser I’m aware of ignores the mimetype and the file extension, and simply checks the first few bytes of the file. All current image types are easily sniffed.
It seems ridiculous this is not also done when downloading a file. I can only think it is intentional. Maybe using the application/octet-stream mimetype was an old way to make sure a file was downloaded, before the content-disposition header was created, and they allow it to maintain backwards compatibility.
It otherwise seems ridiculous to have one behavior for the IMG tag, and another for downloaded images. The code’s already there, why not use it?
It’s for security. Most web servers default to “application/octet-stream” if they are sending a resource of an unknown type. The server is saying " I have no idea what this binary data is" so most browsers are coded to prevent you from loading that directly or setting any default action to take in that situation. They want the user to have to download the file and decide what to do with it. Even loading it to sniff it to find out if it is a JPG or something might compromise the browser’s memory if it were actually malicious code, or possibly cause a system crash at the least.
I’m not positive of this but I think if it is coded inside an IMG tag in an html document being parsed by the browser it is sort of sandboxed to that context and doesn’t present the same risks as someone trying to load it directly from the web server.
The web server tells the browser whether the browser should download the file or display it. Nothing to be concerned about; it’s designed to work that way.
Mac Classic used to use that brilliant Type/Creator code system to determine what type a file was, and also which application should open it, it was far better than MIME types or file extensions.
When everything had to be compatible with the lowest-common-denominator web file systems, all uniqueness died in computers. Shame.
It wasn’t just Classic; they retained that system in the earlier versions of OSX, too. But yes, they eventually abandoned it to be more like everyone else (for values of “everyone else” which mean “almost everyone else”, which in turn means “Windows users”).
Now that the question has been answered I just want to correct the misconception that the file type concept as embodied in the “filename.ext” format was just “aping DEC VMS”. VAX/VMS was an outgrowth of the PDP-11 series, and its operating systems, like the RSX-11 family, RSTS/E, and others, all used filename extensions in just the same way. So did the OS for the PDP-10 before that, which itself was the successor to the PDP-6, and that goes back to 1963. So did OS/8 for the PDP-8.
So in fact the “filename.ext” format was pretty much deeply ingrained throughout the entire DEC product line, going back to the first disk-based operating systems. It was far more fundamental and ubiquitous than your comment would have us believe. And that product line included among the most innovative and brilliantly engineered operating systems ever produced, by anyone, bar none. To suggest that the only “sane” operating systems are those with a Unix background is, I presume, intended as tongue-in-cheek and far from the truth.
