HTTP протокол: основные правила Интернета, которые должен знать каждый веб-разработчик. Как браузер взаимодействует с сервером.

Здравствуйте, уважаемые посетители сайта ZametkiNaPolyah.ru. Продолжим знакомиться с протоколом HTTP в рубрике серверы и протоколы и ее разделе HTTP протокол. В данной записи мы разберемся с тем, что такое медиа тип в HTTP. Для чего используется меди типы в HTTP протоколе. Как расширяются механизмы типизации данных в HTTP. И посмотрим в чем отличие медиа типов HTTP от MIME (стандарт описывающий передачу различных типов данных по электронной почте), также будет рассмотрен синтаксис медиа типов в HTTP.

Медиа типы в HTTP

Если вы хотите узнать всё про протокол HTTP, обратитесь к навигации по рубрике HTTP протокол.  Очередной параметр HTTP – медиа типы. HTTP использует медиа типы интернета в полях заголовка Content-Type и Accept с целью поддержания расширяемой типизации данных. Общий синтаксис медиа типов в HTTP выглядит так:

[php]

media-type = type «/» subtype *( «;» parameter )
type = token
subtype = token
Параметры могут следовать за type/subtype в форме пар атрибут/значение (attribute/value):
parameter = attribute «=» value
attribute = token
value = token | quoted-string
А вот и пример медиа типов в HTTP:
Accept: image/gif

[/php]

Давайте теперь рассмотрим требования HTTP к медиа типам. Тип, подтип, и имена атрибутов и параметров не чувствительны к регистру. Значения параметров могут быть чувствительными к регистру, но могут быть и не чувствительны, в зависимости от семантики имени параметра. Линейный пробел (LWS) не должен использоваться между типом и подтипом, между атрибутом и значением. Агенты пользователей, распознающие медиа типы, должны обрабатывать (или подготавливать для обработки любыми внешними приложениями) параметры для тех типов MIME, которые описаны, и сообщать пользователю о обнаруженных проблемах. Обратите внимание: некоторые старые HTTP приложения не распознают параметры медиа типов. При посылке данных к таким HTTP приложениям реализации должны использовать параметры медиа типов только когда это требуется по определению типа/подтипа. Так же напомню, что совместимость приложения определяется максимальной версией HTTP, которую оно поддерживает.

Медиа подтип text в HTTP

В стандарте HTTP есть меди подтип text, о котором нужно сказать несколько слов отдельно. В канонической форме медиа подтипы типа «text» используют CRLF в качестве метки конца строки. HTTP ослабляет это требование и позволяет передавать текст размеченный таким образом, что единичные CR или LF могут быть метками конца строки, правда это правило должно быть выполнено для всего тела объекта (entity-body). HTTP приложения должны воспринимать CRLF, просто CR, и просто LF как представление конца строки в текстовых типах, переданных по HTTP протоколу. Кроме того, если текст представляется в кодовой таблице (тут нужно вспомнить про кодирование в HTTP), которая не использует октеты 13 и 10 для CR и LF соответственно, что имеет место в некоторых многобайтовых кодовых таблицах, то HTTP позволяет использовать любые последовательности байтов, определенные этим набором символов для представления эквивалентов CR и LF в качестве кода конца строки. Эта гибкость в отношении концов строк применима только к текстовым типам в теле объекта; просто CR или просто LF не должны заменять CRLF внутри любой управляющей структуры HTTP (типа поля заголовка и разделителей типа multipart).

Параметр «charset» используется с некоторыми медиа типами для указания кодовой таблицы, используемой для представления данных. Если параметр «charset» не указан отправителем, то при получении HTTP сообщения медиа подтипы типа «text» имеют значение «charset», по умолчанию равное «ISO-8859-1». Данные в кодовых таблицах или их подмножествах, отличных от «ISO-8859-1» должны быть помечены соответствующим значением «charset».

MIME предусматривает ряд типов «multipart» — формирующих пакет из одного или нескольких объектов внутри тела одного сообщения. Все типы mulptipart используют общий синтаксис, определенный в MIME, и должны содержать разделительный параметр частью значения медиа типа. Тело сообщения — самостоятельный элемент протокола и, следовательно, должно использовать только СRLF для представления концов строк между частями тела (body-parts). В отличие от MIME, окончание любого multipart сообщения должно быть пустым; HTTP приложения не должны передавать окончание (даже если первоначальный multipart содержит заключение).