user1637281
user1637281

Reputation:

Why are mime types not usually set correctly?

Google Chrome debug console reports the following

Resource interpreted as Image but transferred with MIME type application/octet-stream: "http://static7.businessinsider.com/assets/images/faviconBI.ico".

There are many of these all served from other domains.

According to this SO Post this could cause security issues.

What action can I take to get these domains to set the mime types correctly.

I had had this problem before w/ an open source library I used and the author was nice enough to fix his mime type after I emailed him

But in general, it does not seem most domains worry about setting mime types correctly.

How can I mitigate this? ( I don't have the time to do this on a domain by domain basis ).

Upvotes: 2

Views: 309

Answers (1)

freakish
freakish

Reputation: 56467

When you make a request to the server, the server responds with MIME type attached to the response. So if the server does not set the MIME type correctly, then there's nothing you can do.

You could of course write your own proxy, but this will be a proxy. So for example if you have a URL

http://foo.bar/test.js

which comes back with MIME type text/html ( and it should be application/javascript ), then you can write a proxy, which will fetch that URL for you, it will set the correct MIME type and it will push the response to your side. Since proxy will be on a different domain, you will have to access the URL via (for example)

http://proxy/?url=http://foo.bar/test.js

Now obviously it won't help you if you are trying to access existing web pages, because they won't point to proxy's URL.

As for security issues, yeah, in some rare cases MIME type may cause side effects. But to be honest I've never heard about such issues in reality. And if you are going to serve images only, then there's no risk at all.

Now there is a serious performance hit on such proxy, since of course every request has to go via proxy.

Upvotes: 1

Related Questions