Что такое content type

HTTP заголовки | Тип содержимого

Заголовок Content-Type используется для указания типа мультимедиа ресурса. Тип носителя — это строка, отправляемая вместе с файлом с указанием формата файла. Например, для файла изображения его тип носителя будет таким, как image / png или image / jpg и т. Д.

В ответ он сообщает о типе возвращаемого контента клиенту. Браузер узнает о типе контента, который он должен загрузить на компьютер. Каждый раз, когда его байтовый поток файла, который получают браузеры, с помощью заголовка Content-type, браузер будет делать что-то, известное как сниффинг MIME, то есть он будет проверять поток, который он получает, и затем соответствующим образом загружает данные.

Синтаксис:

Директивы: в заголовках HTTP есть три директивы Content-type.

Пример. В этом примере показано, как изображения читаются браузером с настройкой заголовка типа контента и без него.

header( ‘Content-type: image/jpeg’ ); // с заголовком Тип содержимого

Выход :

Теперь, не используя заголовок Content-type, мы получим содержимое изображения в байтах, поэтому оно нам не нужно.

Здесь ясно видно, что, применяя информацию заголовка Content-type, сообщает браузеру, тип ответа, который он получает от сервера.

Все возможные значения заголовка HTTP Content-type:

Поддерживаемые браузеры: браузеры, совместимые с заголовками HTTP, Content-type перечислены ниже:

Источник

Что такое content type

Поле заголовка ‘Content-Type’

Хотя многие параметры (модификаторы подтипов) имеют смысл лишь для конкретного типа, некоторые все же являются глобальными в том смысле. что они применимы ко всем типам (например, параметр «boundary» применим только с типом «multipart», а параметр «charset» может использоваться с несколькими типами).

Пока имен типов только семь, и пока этого достаточно. Кроме того, предполагается, что расширение существующего набора поддерживаемых типов данных будет производиться засчет введения новых подтипов этих изначально определенных типов данных. В будущем добавление имен типов верхнего уровня может быть произведено только при принятии новой версии стандарта MIME. Если по какой-либо другой причине в существующей версии используется незарегестрированный тип содежимого, ему должно быть дано имя, начинающееся с «X-«, чтобы подчеркнуть его нестандартный статус и заранее предупредить конфликт с официальным именем типа, которое может быть введено позднее.

Правильное заполнение поля Content-Type:

Здесь набор специальных символов отличается от набора, определенного в RFC 822 только наличием символов «/», «?», «=» и отсутствием символа «.».

Существует два приемлимых механизма для введения новых подтипов для поля Content-Type:

Семь предопределенных типов верхнего уровня, более детально, представляют собой следующее:

По умолчанию, письма, как и в стандарте RFC 822 пишутся простым (неразмеченным) текстом в языковой кодировке US-ASCII, что по спецификации MIME может быть описано как «Content-type: text/plain; charset=us-ascii». Это значение полагается, если поле Content-type не определено. Поэтому почтовая программа получателя может неверно истолковать содержимое письма, если при отправке не было указано поле Content-type, но на самом деле текст письма имеет другую кодировку или даже тип.

При отсутствии поля Content-type или поля MIME-Version в заголовке MIME-письма нельзя быть точно уверенным, что письмо имеет языковую кодировку именно US-ASCII, поскольку могут еще встречаться почтовые программы, не использующие соглашения MIME. Но хотя возможно, что письмо, не содержащее в заголовке полей MIME-Version и Content-Type, может содержать все, что угодно, например, юниксовский tar-архив, сжатый gzip’ом и обработаный uuencode, все же, создателям почтовых программ рекомендуется оставлять этот факт без внимания и ориентироваться на значение по умолчанию, т.е. «text/plain; charset=us-ascii».

Источник

Интернет технологии (архив ИПМ 2001-2010, Богомолов)

Хотя формат первоначально создан для электронной почты, он также используется для службы WWW.

7.2 Для чего это нужно?

Браузеры используют MIME-типы в своих HTTP-заголовках Accept для того, чтобы сообщить, в каких форматах они предпочитают принимать данные (если сервер может выдать файл в разных форматах). Серверы используют MIME-типы в HTTP-заголовках Content-Type, чтобы сообщить клиенту о том, в каком формате передается прилагаемое содержимое: то ли это HTML, который нужно форматировать, то ли это GIF или JPEG, требующий визуализации, то ли это данные в формате PDF, для которого нужно открывать внешнюю программу просмотра или использовать дополнительное приложение.

Следующий заголовок клиента означает, что принимаются все типы формата text независимо от подтипа:

Действия клиента при получении файла:

При получении клиентом файла, анализируется HTTP заголовок, если в нем находится Content-Type, то клиент производит действие с файлом, учитывая эту информацию.

Если записи нет, то клиент использует свой список MIME-типов, в котором тип определяется по расширению имени файла.

Если тип в файле не найден, то клиент не знает что делать с этим файлом. Браузер в таком случае предлагает вам выбрать сами программу, которой надо передать файл.

7.4 Некоторые основные типы и подтипы MIME.

Последняя версия (состоит из четырех частей) :

RFC2049 (Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples N. Freed, N. Borenstein November 1996)

RFC2048 (Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures N. Freed, J. Klensin, J. Postel November 1996)

RFC2047 (MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text K. Moore November 1996)

RFC2046 (Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types N. Freed, N. Borenstein November 1996)

RFC2045 (Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies N. Freed, N. Borenstein November 1996)

Text – текстовые типы.

Тип ‘text’ предназначен для пересылки текстовых материалов. Для обозначения языковой кодировки текста используется параметр «charset» для некоторых подтипов, включая подтип, «text/html», соответствующий простому (неформатированному) тексту.

Content-Type: text/html; charset=windows-1251

application/msword – приняв такое сообщение, браузер запустит MS Word для открытия этих данных. Если в системе нет MS Word, то браузер попросит сохранить данные в файле имя файла может находиться в параметре name. Например:

Content-Type: application/msword; name=”Mydoc.doc”

7.5 Серверные приложения.

Приложения на сервер можно использовать для создания счетчиков, форумов, чатов, обработки статистики, организации доступа к базам данных и т.д.

Для этого нужно чтобы клиенты могли запускать или работать с приложениями на сервере.

7.5.1 Методы использования серверных приложений.

Приложения, встроенные в сервер HTTP, как модули. Как правило, написанные на С.
Преимущества:
— быстрота (т.к. всегда работает, не нужен запуск).
Недостатки:
— необходимость писать модуль для конкретного сервера HTTP.

Приложения, работающие через модули-шлюзы встроенные в сервер HTTP.
Преимущества:
— шлюз написан для конкретного приложения (например, для СУБД MySQL)
Недостатки:
— необходимость писать модул-шлюз для конкретного приложения.

Приложения, работающие через Java Servlet.
Преимущества:
— платформо-независимость
— серверо-независимость
Недостатки:
— приложения на Java работаю медленнее

7.5.2 Архитектура WWW сервера с учетом серверных приложений

Архитектура современного WWW сервера. На выходе с сервера всегда HTML, но сгенерированный приложением.

7.5.3 Примеры запросов к приложениям

В результате через CGI шлюз

Будет запущено приложение search.cgi

и будет передан запрос «text=сотрудники» приложению search.cgi

Приложение search.cgi вернет результат работы CGI-шлюзу

Будет передан запрос «text=сотрудники» интерпретатору PHP.

Интерпретатор будет выполнять команды search.php.

Интерпретатор вернет результат работы WWW-серверу.

7.6.1 Механизмы обмена данными

Механизм можно разделить на четыре части:

7.6.1.1 Переменные окружения

При запуске внешней программы сервер создает специфические переменные окружения, через которые передает приложению, как служебную информацию, так и данные.

Идентификация пользователя и его машины:

Тип и длина передаваемой информации от клиента к серверу.

Переменные заголовка HTTP.

7.6.1.2 Командная строка

Командная строка используется только при запросах типа ISIN-DEX.

Источник

MIME types

Организация Internet Assigned Numbers Authority (IANA) является ответственной за все официально признанные MIME типы, и вы можете найти самый последний и полный лист MIME типов на их странице Медиа Типов.

Важно: Для принятия решения о том, как обрабатывать URL, браузеры используют MIME типы, а не расширения файлов, так что серверам необходимо отправлять правильные MIME типы в Content-Type заголовке ответа. При неточном задавании этого заголовка, браузеры с большой вероятностью будут неправильно интерпретировать и обрабатывать содержание файлов, из-за чего сайт будет работать неверно.

Структура MIME типа

Простейший MIME тип состоит из типа и подтипа — двух строк разделённых наклонной чертой ( / ), без использования пробелов.

Необязательный параметр может быть добавлен для указания дополнительных деталей

MIME типы являются нечувствительными к регистру, но традиционно их пишут строчными буквами, за исключением значений параметров.

Все типы можно разделить на два класса: дискретные и многокомпонентные. Дискретные типы представляют одиночные файлы, например, одиночный текстовый, музыкальный или видео файл. Многокомпонентные типы представляют документы, составленные из нескольких частей, каждая из которых может иметь свой отдельный MIME тип, или они могут заключать в себе несколько отдельных файлов, передаваемых в одном сообщении. Например, многокомпонентные MIME типы используются для передачи нескольких изображений в одном email.

Дискретные типы

В настоящее время на IANA зарегистрированы следующие дискретные типы:

Любые текстовые документы без определённого подтипа стоит отправлять, как text/plain тип. Аналогичным образом, application/octet-stream тип подойдёт бинарным документам при неопределённом или неизвестном подтипе.

Многокомпонентные типы

Многокомпонентные типы описывают категории разграниченных на части документов, где каждая из частей может иметь свой отдельный MIME тип. При работе с электронными письмами, они могут использоваться для описания нескольких отдельных файлов, передаваемых в одном сообщении. Они представляют составные документы.

За исключением multipart/form-data типа, используемого в POST методе HTML форм, и multipart/byteranges типа, используемом в ответе 206 Partial Content для отправки части документа, HTTP никаким особым образом не обрабатывает многокомпонентные типы, и просто отправляет данные в браузер (который, с большой вероятностью, предложит сохранить переданный файл, тоже не зная как его обработать).

Существуют два многокомпонентных типа:

Важные для Web-разработчиков MIME типы

application/octet-stream

text/plain

Этот тип является базовым для текстовых файлов. Несмотря на то, что он означает «неопределённые текстовые данные», браузеры всё равно могут его отображать.

Заметьте: text/plain не означает «любой вид текстовых данных». Если браузер ожидает получения какого-то конкретного типа текстовых данных, то с большой вероятностью он не будет считать text/plain подходящим типом. Например, при загрузке text/plain документа через элемент, браузер не будет его признать правильным CSS файлом и использовать для применения стилей. Только text/css тип должен использоваться для загрузки CSS документов.

text/css

CSS документы, используемые для стилизации web-страниц должны отправляться, как text/css тип. Большинство браузеров не смогут распознавать CSS документы, загруженные с отличным от text/css MIME типом.

text/html

Все HTML данные должны пересылаться с данным типом. Альтернативные MIME типы для XHTML (например, application/xhtml+xml ) почти не используются в настоящее время.

text/javascript

По исторически сложившимся причинам, MIME Sniffing Standard (стандарт, определяющий, как браузеры должны интерпретировать медиа типы и выяснять, как обрабатывать данные при неправильно заданных медиа типах) позволяет серверам отправлять JavaScript документы, используя один из нижеперечисленных типов:

Типы изображений

Лишь несколько типов изображений достаточно распространены, чтобы безопасно использоваться на веб-страницах.

Аудио и видео типы

Так же как в случае с изображениями, стандарт HTML не обязывает браузеры поддерживать какие-либо определённые форматы и кодеки для и элементов, так что при их выборе, важно брать в расчёт целевую аудиторию и диапазон браузеров (а так же версии этих браузеров), которые она может использовать.

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

Руководства по аудио и видео кодекам перечисляют часто поддерживаемые браузерами кодеки, предоставляя детали по их совместимости и техническую информацию, например как много аудио каналов они поддерживают, какой тип сжатия используют, и так далее. Руководство по используемым в WebRTC кодекам развивает эту тему ещё дальше, конкретно описывая кодеки, поддерживаемые популярными браузерами, так чтобы вы могли выбрать кодеки, которые имеют наилучшую поддержку в диапазоне браузеров по вашему выбору.

Что касается MIME типов для аудио и видео файлов, то чаще всего они указывают на формат контейнера (тип файла). Необязательный параметр codecs может быть добавлен к MIME типу для более точного указания, какой кодек и параметры использовались для пересылаемого файла.

Ниже перечислены наиболее часто используемые на веб-страницах MIME типы. Обратите внимание, что это не полный перечень всех доступных типов. Более полный список поддерживаемых форматов может быть наеден в руководстве по медиа форматам.

multipart/form-data

multipart/form-data тип может быть использован при отправке значений из заполненной HTML Формы на сервер.

Источник

Каковы все возможные значения для заголовка HTTP «Content-Type»?

Я должен проверить Content-Type значение заголовка, прежде чем передать его в запрос HTTP.

Иначе, есть ли способ проверить тип контента перед использованием его в HTTP-запросе?

Наиболее распространенный тип:

В расширенной нотации BNF RFC 822 значение поля заголовка Content-Type определяется следующим образом:

Content-Type: = type «/» subtype * [«;» параметр]

type: = «application» / «audio» / «image» / «message» / «multipart» / «text» / «video» / x-token

параметр: = атрибут «=» значение

значение: = токен / строка в кавычках

tspecials: = «(» / «)» / » » / «@»; Должен быть в / «,» / «;» / «:» / «\» / ; строка в кавычках, /» / «/» [«/»] «/»? «/». «; использовать в /» = «; значения параметров

И список известных типов MIME, которые могут следовать за ним (или, как замечает Джо, источник IANA ).

Как видите, список слишком велик для вас, чтобы его можно было проверить по всем. Что вы можете сделать, это проверить на соответствие общему формату и type атрибуту, чтобы убедиться, что это правильно (набор опций невелик), и просто предположить, что то, что следует, является правильным (и, конечно, перехватить любые исключения, с которыми вы можете столкнуться, когда вы положите его для фактического использования).

Также обратите внимание на комментарий выше:

Если по какой-либо причине должен использоваться другой первичный тип, ему нужно дать имя, начинающееся с «X-», чтобы указать его нестандартный статус и избежать возможного конфликта с будущим официальным именем.

Вы заметите, что во многих HTTP-запросах / ответах есть какой-то X- заголовок, который определяется самостоятельно, помните об этом при проверке типов.

Источник