Требуется ли HTTP-заголовок Content-Type?

Этот вопрос касается поведения браузера, а также спецификации протокола для связывания, импорта, включения или ajaxing CSS, JS, изображений и других ресурсов из файлов HTML, JS или CSS.

При тестировании статических файлов и доставки сжатого контента в разных браузерах я обнаружил, что некоторые браузеры начинают вести себя по-разному, если вы отойдете от соглашений. Например, IE6 создает проблему, если вы не отправляете Content-Disposition: inline; заголовок для всех встроенных файлов css, js и т.д., а последняя версия safari неправильно обрабатывает предварительно сжатые CSS файлы gzip, если вы используете расширение .gz как в main-styles.css.gz.

Мой вопрос о поведении браузеров относительно заголовка ответа Content-Type. Так как теги <link>, <script> и <img> уже разумно указывают тип содержимого ресурса, можно ли безопасно пропустить этот заголовок, или некоторые браузеры требуют его по какой-то исторической причине?

Ответ 1

Короче говоря, нет, это не требуется. Но он рекомендовал. Большинство браузеров, о которых я знаю, будут относиться к <link>, <script> и <img> правильно, если они не отправляются с заголовками, но нет никакой реальной причины не отправлять заголовки. В принципе, без заголовков Content-Type браузер остается попробовать и угадать на основе содержимого.

Из RFC2616:

Content-Type указывает тип медиафайлов базовых данных.
Content-Encoding может использоваться для указания любого дополнительного контента
кодировки, применяемые к данным, обычно для целей данных сжатия, которые являются свойством запрашиваемого ресурса. Существует без кодировки по умолчанию.

Любое сообщение HTTP/1.1, содержащее тело объекта, ДОЛЖНО включать в себя Поле заголовка Content-Type, определяющее тип носителя этого тела. Если
и только в том случае, если тип носителя не задан поле Content-Type, получатель МОЖЕТ попытаться угадать тип носителя через проверку его контента и/или расширений (имен) имени URI, используемых для идентификации ресурс. Если тип носителя остается неизвестным, получатель ДОЛЖЕН
рассматривайте его как тип "application/octet-stream".

Относительно ключевого слова SHOULD, указанного в RFC2119:

СЛЕДУЕТ: Это слово или прилагательное "РЕКОМЕНДУЕТСЯ" означает, что там могут существовать обоснованные причины в особых обстоятельствах, чтобы игнорировать конкретный элемент, но все последствия должны быть поняты и
тщательно взвешивается перед выбором другого курса.

Ответ 2

Я столкнулся с проблемой в java, где я попытался опубликовать некоторые данные через библиотеку chrriis.dj.nativeswing.swtimpl.components.JWebBrowser, которая в основном отображает Internet Explorer внутри java-программы. Но простой php script на back-end не будет анализировать мои данные после ввода. (Используемые параметры WebBrowserNavigationParameters для установки пост-данных во время перехода на определенную страницу) Я, наконец, узнал, что заголовок Content-Type должен быть установлен для правильной вставки post-data. (Это не было установлено по умолчанию.) Настройка его на Content-Type: application/x-www-form-urlencoded, и все сработало нормально. Поэтому, полагаю, установка Content-Type всегда должна выполняться при отправке данных на php.

Ответ 3

Требуется для обратной совместимости.

Например: Internet Explorer 10 требуется Content-Type:image/svg+xml, чтобы отобразить любой файл svg

IE10, IE9, и, возможно, другим браузерам всегда нужен заголовок Content-Type.