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?
No, it's not mandatory. Per the HTTP 1.1 specification: Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body.
Common Response HeadersThe first line of the response is mandatory and consists of the protocol ( HTTP/1.1),response code (200)and description (OK). The headers shown are: CONTENT-Type -This is Text/html which is a web page. It also includes the character set which is UTF-8.
The Content-Type representation header is used to indicate the original media type of the resource (prior to any content encoding applied for sending). In responses, a Content-Type header provides the client with the actual content type of the returned content.
Generally the Content-Length header is used for HTTP 1.1 so that the receiving party knows when the current response* has finished, so the connection can be reused for another request. Alternatively, Content-Length header can be omitted and a chunked Transfer-Encoding header can be used.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With