A Simple but Critical HTTP Header Mistake

When it comes to setting HTTP charset parameters, such as the Content-Type field, it is usually fairly straightforward. When documents that are to be sent by a server to a user agent (i.e. – a browser) are of the type text, the HTTP header line will generally appear as follows:

Content-Type: text/html; charset=utf-8

What happens, though, when documents that are of type text have Content-Type mistakenly set to image/jpeg?

Obstruction.

First, this erroneous server setting can obstruct browsers from effectively loading site pages. When a browser is told that the data type is in the format of an image/jpeg, the content of text/html pages will not load in certain browsers. While some versions of browsers may load such a page correctly, others will not, which is certainly not ideal.

Second, assigning the wrong Content-Type to text/html pages can also obstruct a search engine’s ability to access these pages. This is undeniably problematic as your site will have no hope of attaining any type of presence in the search engines, even for your brand name. A good way to check to see how engines are viewing your pages is to use a text-only browser, such as Lynx.

While this is a rare occurrence, it is an issue which I have seen before, and one that you should be wary of, especially if your site pages aren’t rendering in certain browsers.

To associate character encoding with your files, you can specify by extension.

For Apache, you can serve all files with a particular extension, such as .html, as text/html by using the .htaccess file.

For IIS 5 and 6, use IIS Manager to associate character encoding for each extension by going to ‘Properties’ > ‘HTTP Headers’ > ‘File Types’ > ‘New Type’. Add the particular extension you want to map along with the appropriate Content-Type.