Всегда ли требуется HTTP-заголовок Content-Type?
Этот вопрос относится к поведению браузера, а также к спецификации протокола для связывания, импорта, включения или изменения CSS, JS, изображений и других файлов с веб-страниц, js-файлов или css-файлов.
При тестировании статических файлов и доставки сжатого контента я обнаружил, что лишь немногие браузеры создают проблемы, если вы отходите от соглашений. Как: IE6 создает проблему, если вы не отправляете Content-Disposition: inline; заголовок для всех встроенных файлов CSS, JS и т. д., и не слишком старая версия safari неправильно обрабатывает сжатые CSS-файлы, если вы используете расширение файла .gz как в main-styles.css.gz,
Я хочу спросить о поведении браузеров о Content-Type заголовок ответа. поскольку <link>, <script> а также <img> Вы уже указали тип контента, можно ли безопасно пропустить этот заголовок или в некоторых браузерах по какой-то причине?
3 ответа
Короче, нет, это не обязательно. Но это рекомендуется. Большинство браузеров, о которых я знаю, будут относиться <link>, <script>, а также <img> правильно, если они не отправлены с заголовками, но нет действительно веской причины не отправлять заголовки. В основном без Content-Type заголовки, браузер оставлен, чтобы попытаться угадать на основе содержимого.
Из RFC2616:
Content-Type определяет тип носителя базовых данных.
Content-Encoding может использоваться для указания любого дополнительного контента
кодировки, применяемые к данным, обычно для целей данных
сжатие, которые являются свойством запрашиваемого ресурса. Есть
нет кодировки по умолчанию.Любое сообщение HTTP/1.1, содержащее тело объекта, ДОЛЖНО включать
Поле заголовка Content-Type, определяющее тип носителя этого тела. Если
и только если тип мультимедиа не задан полем Content-Type,
получатель МОЖЕТ попытаться угадать тип носителя путем проверки его
содержимое и / или расширение (я) имени URI, используемого для идентификации
ресурс. Если тип носителя остается неизвестным, получатель ДОЛЖЕН
трактуйте это как тип "application/octet-stream".
Относительно ключевого слова СЛЕДУЕТ, указанного в RFC2119:
СЛЕДУЕТ: Это слово, или прилагательное "РЕКОМЕНДУЕТСЯ", означает, что там
могут существовать веские причины в определенных обстоятельствах игнорировать
конкретный пункт, но все последствия должны быть поняты и
тщательно взвесить, прежде чем выбрать другой курс.
Требуется для обратной совместимости.
Например: Internet Explorer 10 потребности Content-Type:image/svg+xml для того, чтобы сделать любой SVG- файл
IE10, IE9 и, возможно, другие браузеры всегда нуждаются в Content-Type заголовок.
Я столкнулся с проблемой в Java, где я попытался опубликовать некоторые данные через библиотеку chrriis.dj.nativeswing.swtimpl.components.JWebBrowser, которая в основном отображает Internet Explorer внутри Java-программы. Но простой скрипт php на бэкэнде не будет анализировать мои пост-данные. (Использовал WebBrowserNavigationParameters для установки данных поста при переходе на определенную страницу) В конце концов я обнаружил, что для правильной вставки постданных в php должен быть установлен заголовок Content-Type. (Это не было установлено по умолчанию.) Установите его в Content-Type: application/x-www-form-urlencoded и все работало нормально. Итак, я полагаю, что установка Content-Type всегда должна выполняться при размещении данных в php.