This question is about browser behavior as well as protocol specification for linking, importing, including or ajaxing css, js, image and other resources from within html, js or css files.
While testing static files and compressed content delivery in different browsers, I found that some browsers start behaving differently if you move away from conventions. For example, IE6 creates problem if you do not send Content-Disposition: inline; header for all inline css and js etc files, and a recent version of safari does not properly handle pre-compressed gzip CSS files if you use file extension .gz like in main-styles.css.gz.
My question is about the behavior of browsers about Content-Type response header. Since <link>, <script> and <img> tags already reasonably specify the content type of the resource, can this header be safely skipped, or do some browsers require it for some historical reason?
In short, no, it's not required. But it's recommended.
Most browser that I know of will treat <link>, <script>, and <img> properly if they are not sent with headers, but there's no real good reason not to send the headers. Basically, without Content-Type headers, the browser is left to try and guess based on the content.
From RFC2616:
Content-Type specifies the media type of the underlying data.
Content-Encoding may be used to indicate any additional content
codings applied to the data, usually for the purpose of data
compression, that are a property of the requested resource. There is
no default encoding.
Any HTTP/1.1 message containing an entity-body SHOULD include a
Content-Type header field defining the media type of that body. If
and only if the media type is not given by a Content-Type field, the
recipient MAY attempt to guess the media type via inspection of its
content and/or the name extension(s) of the URI used to identify the
resource. If the media type remains unknown, the recipient SHOULD
treat it as type "application/octet-stream".
Regarding the keyword SHOULD, specified in RFC2119:
SHOULD: This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
I ran into a problem in java where I tried to post some data via the library chrriis.dj.nativeswing.swtimpl.components.JWebBrowser, which basically displays an internet explorer inside a java program. But the simple php script on the back-end would not parse my post-data. (Used WebBrowserNavigationParameters to set post data while navigating to a certain page) I finally found out that the Content-Type header had to be set for php to properly paste the post-data. (This was not set by default.) Setting it to Content-Type: application/x-www-form-urlencoded and everything worked fine. So, I guess setting Content-Type should allways be done when POSTing data to php.
It is required for backward compatibility.
For example: Internet Explorer 10 needs Content-Type:image/svg+xml in order to render any svg file
IE10, IE9 and probably other browsers always need the Content-Type header.
