What are the implications of serving different file types all as application/octet-stream in a web application?

问题

My well-answered question here on SO has led to another question.

The Azure account I mention in that original question is not managed by us. Here is an example of the headers received when requesting its blob files:

HTTP/1.1 200 OK
Content-MD5: R57initOyxxq6dVKtoAx3w==
Content-Type: application/octet-stream
Date: Wed, 02 Mar 2016 14:32:35 GMT
Etag: 0x8D3180DA8EBF063
Last-Modified: Fri, 08 Jan 2016 09:25:33 GMT
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
x-ms-blob-type: BlockBlob
x-ms-lease-status: unlocked
x-ms-request-id: 19d0a689-0001-0039-2990-74a33e000000
x-ms-version: 2009-09-19
Content-Length: 263748

So the files are being returned as application/octet-stream which I understand effectively means unknown file type. When I hit the URL in a browser I'm prompted to download, even when the file is an image.

Ultimately the files in this blob storage will be used in 2 ways. Some are images which will be used for website imagery. Others are 'assets' (mainly PDFs) which need to be downloaded as opposed to opened in the browser.

So my question is, if I leave the blob storage as is, with all assets being returned as application/octet-stream, are there any negative implications when using its images as web content and linking to its PDFs for download? e.g. are there browsers which will behave differently?

In other words, what advantage would there be if I insisted the headers were changed to...

Content-Type: image/png
Content-Disposition: inline; filename="picture.png"

...and...

Content-Type: application/pdf
Content-Disposition: attachment; filename="file.pdf"

回答1:

So my question is, if I leave the blob storage as is, with all assets being returned as application/octet-stream, are there any negative implications when using its images as web content and linking to its PDFs for download? e.g. are there browsers which will behave differently?

Yes, browsers behave differently. For example, if you have a png file stored in Azure Blob Storage with content type as application/octet-stream, in Chrome it will always be downloaded but in Internet Explorer it will be displayed. So in essence you're left at browser's mercy as to how they deal with the content based on it's type.

Ultimately the files in this blob storage will be used in 2 ways. Some are images which will be used for website imagery. Others are 'assets' (mainly PDFs) which need to be downloaded as opposed to opened in the browser.

It is recommended that you set the content type properly for the content you want to display in the browser. Even for the content that will be downloaded, please ensure that the content type is set properly. For downloadable content, there are 2 scenarios that you may want to consider:

1. Content will always be downloaded: If the content will always be downloaded, you could set the content-disposition property of the blob to attachment; filename="file.pdf".
2. Content sometimes will be downloaded but sometimes it will be presented inline: In this scenario, don't set the content-disposition property of the blob and set its content type properly. So when the content is accessed, by default it will be displayed inline. When you need to force download the content, you could create a Shared Access Signature (SAS) on the blob with at least Read permission and override content-disposition property of the blob in SAS. When someone access the blob using SAS URL, the content will always be downloaded.

来源：https://stackoverflow.com/questions/35752650/what-are-the-implications-of-serving-different-file-types-all-as-application-oct