Http сообщение rfc 2068


Содержание

Что такое заголовки в протоколе HTTP.

Когда мы разбирали общую структуру HTTP запросов и ответов, то одной из частей, из которой эта структура состояла, являлись HTTP заголовки (Message Headers). Давайте сейчас подробнее рассмотрим, что это такое.

Заголовки – это специальные параметры, которые несут определенную служебную информацию о соединении по HTTP. Некоторые заголовки имеют лишь информационный характер для пользователя или для компьютера, другие передают определенные команды, исходя из которых, сервер или клиент будет выполнять какие-то действия.

В зависимости от того, где эти заголовки могут находиться, они разделяются на:

General Headers (Основные заголовки) — должны быть и в запросах и в ответах клиента и сервера.

Request Headers (Заголовки запроса) — используются только в запросах клиента.

Response Headers (Заголовки ответа) — используются только в ответах сервера.

Entity Headers (Заголовки сущности) — сопровождают каждую сущность сообщения.

Каждый заголовок имеет следующий вид:

Немного о правилах написания, что нужно иметь в виду:

1) Регистр (большие или маленькие буквы) здесь не учитываются. Можно писать и так и так.

2) Пишутся латинскими буквами.

3) После параметра должен идти символ двоеточия (:)

4) Окончанием пары «параметр:значение» служит символ переноса строки.

Вот, примеры некоторых заголовков:

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

Если вы знаете английский, то почитать о них можно в оригинале на страницах стандарта HTTP 1.1.

Кроме того, есть перевод этого стандарта на русский язык здесь:

Есть еще хорошая табличка, которая опубликована на страницах википедии:

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

Яндекс Метрика и Google Analytics. Цели, события, отчеты.

ИТ База знаний

ShareIT — поделись знаниями!

Полезно

Узнать IP — адрес компьютера в интернете

Онлайн генератор устойчивых паролей

Онлайн калькулятор подсетей

Калькулятор инсталляции IP — АТС Asterisk

Руководство администратора FreePBX на русском языке

Руководство администратора Cisco UCM/CME на русском языке

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Похожие статьи

SDN сети

Установка Hadoop – надуваем слоника

Топ — 5 FTP клиентов для Linux

Нужно знать: утилита lsof в Linux

HyperText Transfer Protocol (HTTP)

Работает прямо сейчас

4 минуты чтения

The HyperText Transfer Protocol, или HTTP, это самый распространенный в мире протокол уровня приложений модели OSI на сегодняшний день. Протокол HTTP образует пространство, которое большинство людей называют сетью Интернет. Основной задачей протокола HTTP является извлечение HTML (HyperText Markup Language) или любых других документов с WEB – сайтов через сеть Интернет. Каждый раз, когда вы открываете интернет — браузер, в дело вступает протокол HTTP, оперируя поверх стека протоколов TCP/IP.

Протокол HTTP был впервые выпущен на свет вначале 1990 года и имел три версии:

  • HTTP/0.9: Простейшая реализация протокола, позволяющая только получать WEB – страницы
  • HTTP/1.0: Даная версия обнародована Инженерным советом Интернета (Internet Engineering Task Force, IETF) в рамках RFC 1945 в 1996 году. В данной версии было добавлено большое количество дополнительных полей, именуемых заголовками в этой спецификации. Эта версия протокола расширяла взаимодействие между клиентом и сервером.
  • HTTP/1.1: Версия 1.1 определена в RFC 2068 советом IETF как доработанная и улучшенная версия протокола HTTP поверх спецификации 1.0. Одним из самых заметных улучшений версии 1.1 по сравнению с 1.0 стало внедрений методов постоянных TCP сессий, возможность отправки нескольких HTTP запросов одновременно, не дожидаясь ответа сервера (повышение скорости работы) и реализация алгоритма кэширования.

На сегодняшний день, большинство современных интернет – браузеров поддерживают обе версии 1.0 и 1.1 протокола HTTP. Важно отметить, что современные браузеры обеспечивают полную совместимость данных версий, то есть при условии отправки запрос версии 1.0 и получения ответа 1.1, данные будут успешно обработаны.

Получение веб страницы по HTTP

Рассмотрим процесс получения WEB – страницы обычным интернет браузером с сервера. Любая HTML страница содержит в себе множество объектов, тэгов и изображений. В целом, HTML можно рассматривать как структуру страницы, в которой все объекты расставлены на свои места. В свою очередь, интернет – браузер получает инструкции в рамках этого HTML документа, откуда брать шрифты, цвета, фон и прочие элементы оформления страницы. Порядок таков:

  1. Клиент (браузер) отправляет запрос на WEB – сервер для запрашиваемой страницы.
  2. Сервер анализирует запрос и отправляет HTML код необходимый для формирования страницы.
  3. Клиент начинает анализировать полученный документ и формировать WEB – страницу.
  4. Клиент в последующих запросах будет формировать изображения, видео или любую другую форму внутренних объектов из источников WEB – сервера.

Когда все элементы страницы получены, клиент (интернет браузер) отобразит запрошенную WEB – страницу. Порядок и время работы зависят от версии протокола (1.0 или 1.1).

HTTP запросы

Протокол HTTP (HyperText Transfer Protocol) позволяет не только получать HTML документы с Web – серверов, но и передавать информацию от клиента к серверу. Заголовки запросов в протокол HTTP версий 1.0 и 1.1 указаны в таблице ниже:

Запрос Описание HTTP/1.0 HTTP/1.1
GET Это запрос почти аналогичен запросу GET. Отличие в том, что сервер не должен возвращать в ответ содержание HTML, а только HTTP заголовок. Да Да
HEAD Это запрос почти аналогичен запросу GET. Отличие в том, что сервер не должен возвращать в ответ содержание HTML, а только HTTP заголовок. Да Да
HEAD Это запрос почти аналогичен запросу GET. Отличие в том, что сервер не должен возвращать в ответ содержание HTML, а только HTTP заголовок. Да Да
POST Позволяет клиенту отправлять информацию в сторону сервера, например через различные встроенные в сайт формы Да Да
PUT Позволяет клиенту добавить файл в определенную директорию сервера. Нет Да
DELETE Позволяет клиенту удалить файл указанный в рамках запроса. Нет Да
TRACE Позволяет клиенту отслеживать свой запрос к серверу. Нет Да
OPTIONS Позволяет клиенту определять параметры взаимодействия с сервером. Нет Да

В стандартном понимании Web – сайта, запросы GET и POST являются наиболее часто используемыми. Метода GET используется клиентом для получения каждого отдельного объекта страницы, в то время как POST зачастую используется в интернет магазинах, где необходимо отправить информацию в строну сервера.


Что такое URL?

Uniform Resource Locator (URL) одна из самых важных составляющих любого GET запроса, который состоит из хоста, на котором находится сайт, схемы обращения (сетевой протокол) и полного пути к HTML файлу. Опционально, URL может содержать в себе информацию о номере TCP порта и определенной точки на странице. Ниже приведен типичный пример URL:

Полезна ли Вам эта статья?

Пожалуйста, расскажите почему?

Нам жаль, что статья не была полезна для вас :( Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

Подпишитесь на нашу еженедельную рассылку, и мы будем присылать самые интересные публикации :) Просто оставьте свои данные в форме ниже.

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

Что нужно знать про HTTP протокол веб-разработчику. Правила HTTP протокола

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

Всё, что тебе нужно знать про HTTP протокол

Что такое HTTP протокол?

Давайте дадим определение тому, что такое HTTP протокол, но, прежде чем дать определение термину HTTP протокол, давайте разберемся со словом протокол. Слово протокол переводится с греческого дословно, как первый и клей. В древности это был листок, который клеился к свитку и на нем автор писал свое имя, дату написания и прочую никому ненужную информацию, вернее, служебную. Почему я говорю ненужную? Да потому, что рядовому обывателю интереснее само содержание свитка, а не то, кто его написал. Так и в HTTP протоколе: среднестатистическому пользователю вообще неинтересно как он получает страницы сайта, он просто открывает свой браузер. Еще одно определение слова протокол – это алгоритм, либо последовательность действий. Протокол – это свод правил и предписаний, которые регламентируют то или иное мероприятие. Протокол передачи данных – это стандарт, описывающий правила взаимодействия функциональных блоков при передаче данных.

Итак, мы определились, что HTTP – это протокол передачи данных, но что означает аббревиатура HTTP? HTTP или HyperText Transfer Protocol – это протокол передачи гипертекста. А теперь я приведу наиболее интересные определение HTTP протокола, которые когда-либо встречал.

HTTP протокол – это правила дорожного движения в интернете, только если в жизни люди могут не соблюдать правила дорожного движения и им за это ничего не будет, то несоблюдение правил HTTP протокола ведет к тому, что пользователь не сможет работать в интернете.

HTTP протокол – это протокол передачи данных седьмого уровня модели OSI, работающий на основе технологии клиент-сервер.

HTTP протокол – это абстракция над третьи и четвертым уровнем эталонной модели, расширяющая возможности коммуникаций между людьми.

HTTP протокол – изначально простой протокол передачи гипертекста, по которому сейчас можно передавать все, что угодно.

HTTP протокол – это транспорт для других протоколов, например, так как JSON.

HTTP протокол – это технология, которую должен понимать любой веб-разработчик.

Что же, я думаю, мы разобрались с тем, что такое HTTP протокол и можем теперь посмотреть, где он используется.

Для чего используется HTTP протокол

Скажу прямо HTTP протокол – это основа интернета, точнее не так, это та основа, которую видит конечный потребитель: посетители сайтов. Поэтому HTTP протокол в интернете везде. Фраза странно звучит, но другой я придумать не смог. Читая новости на сайте, вы используете HTTP протокол. Слушая музыку Вконтакте, вы используете HTTP протокол. Когда вы смотрите видео на YouTube – вы используете HTTP протокол. Когда вы играете в браузерную игру, вы тоже используете HTTP протокол. Поэтому я и пишу, что HTTP протокол используется везде в интернете. Без него вы бы не смогли и этот текст прочитать. Подведем итог: HTTP протокол используется для передачи данных в интернете, изначально он использовался для передачи HTML документов, но сейчас он позволяет передавать различный контент и различные типы данных.

Характеристики HTTP протокола

Давайте перечислим технические характеристики HTTP протокола:

  1. HTTP протокол работает по технологии клиент-сервер.
  2. HTTP протокол относится к седьмому уровню модели OSI.
  3. HTTP протокол относится к семейству протоколов TCP/IP.
  4. Для передачи данных по протоколу HTTP используется порт 80 TCP или 8080.
  5. Спецификация протокола RFC 2616.
  6. Для идентификации ресурса HTTP протокол использует URI (читай про URI в HTTP).
  7. HTTP протокол не имеет промежуточных состояний между запросом и ответом, конечно, клиент может получить ответ с кодом 100, но это ведь уже ответ, а не промежуточное состояние.
  8. HTTP протокол синхронный, но позволяет клиенту отправлять несколько запросов подряд, не дожидаясь ответа сервера, при условии, что сервер даст ответы на запросы в том порядке, как они приходили.

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

HTTP протокол работает по принципу клиент-сервер

Да, HTTP протокол работает по принципу клиент-сервер. Самый простой пример, что приходит мне сейчас в голову, дабы объяснить суть взаимодействия клиент-сервер, это пример покупателя и продавца в магазине. Покупатель приходит в магазин и говорит продавцу: Здрасти!. Если продавец грубый, он отвечает: забор покрасти!. Дальше покупатель улыбается, стоит, смотрит на витрину и выбирает: чего бы ему купить. А в это время продавец стоит и молчаливо ждет, пока клиент выберет. Клиент сделал выбор и говорит продавцу: а дайте мне вон ту коричневую хрень, что стоит на верхней полке в дальнем углу. Продавец говорит: щас. После чего берет табурет ставит его в дальний угол, снимает с полки коричневую хрень и несет покупателю. Покупатель берет коричневую хрень, отдает деньги и уходит. А продавец, получив деньги, кладет их в кассу.

Суть этой истории в том, чтобы показать взаимодействие клиент-сервер. Клиент (в данном случае покупатель) полностью управляет развитием событий, то есть сервер (в нашем примере продавец) ни в коем случае сам не устанавливает контакт, он терпеливо ждет действий клиента и каким-то образом на них реагирует. Я привел самый простой пример. Но его можно и усложнить, например, покупатель дает сто рублей, а коричневая хрень стоит 90, в этом случае продавец даст клиенту сдачу. Продавец мог отреагировать на слова клиента: Здрасти!, как-нибудь по-другому. Или коричневая хрень могла быть не для продажи или для продажи, но только для особых клиентов. Я это веду к тому, что HTTP протокол – это протокол передачи данных основанный на взаимодействие клиент-сервер и он, в принципе, довольно полно описывает алгоритмы действия как для клиента, так и для сервера в различных ситуациях.

История HTTP: стандарты HTTP протокола

Давайте теперь рассмотрим историю HTTP протокола на его стандартах.

  1. Стандарт HTTP/0.9 – версия протокола HTTP9 была разработана в 1991 году в ЦЕРН Тимом Бернерсом-Ли. Тим разработал HTTP протокол для облегчения доступа и создания навигации при помощи гипертекста. Стандарт HTTP/0.9 содержит в себе основы синтаксиса и семантики протокола HTTP.
  2. В 1996 году был выпущен информационный документ RFC 1945 (стандарт HTTP/1.0).
  3. В 1997 году была выпущена версия протокола HTTP1: был разработан стандарт HTTP/1.1 и описан он в документе RFC 2068. В 1999 году был доработан стандарт HTTP/1.1 (именно стандарт HTTP/1.1). На данный момент большинство приложений для своей работы используют HTTP протокол версии 1.1. Кстати, HTTP приложения могут себя идентифицировать, посылая информацию о себе в заголовке.
  4. 2015 году была опубликована финальная версия черновика протокола HTTP 2, это еще не стандарт, но черновик нам «показывает» куда будет двигаться развитие интернета.

Клиенты HTTP протокола

Самым распространенным примером клиента HTTP протокола является браузер, вот самые популярные клиенты HTTP протокола:

  • Google Chrome;
  • Mozilla FireFox;
  • Opera;
  • Internet Explorer;
  • Яндекс Браузер;
  • Safari.

Часто вместо термина клиент вы можете услышать агент пользователя, знайте, что HTTP протокол не делает никаких различий между терминами клиент и агент пользователя.

Серверы HTTP протокола

Серверы HTTP протокола можно условно разделить на два вида: исходные сервера и прокси-сервера. К исходным серверам относятся те сервера, к которым непосредственно обращается клиент, прокси-сервера HTTP – это транзитные сервера между клиентом и тем сервером, к которому он желает обратиться. Зачастую бывает так, что HTTP сервер выполняет одновременно функцию и конечного сервера, и прокси-сервера, а иногда и клиента.

Вот примеры конечных HTTP серверов:

Давайте посмотрим на прокси-сервера:

На самом деле список гораздо шире, хочу обратить ваше внимание на то, что внутренняя реализация у серверов может быть разной, но правила HTTP протокола они должны выполнять в точности. Для обычного пользователя работа сервера – это его интимное дело, а вот у веб-администратора есть необходимость знать тот или иной программный продукт, чтобы сделать работу пользователя или разработчика наиболее эффективной и комфортной.

Требования HTTP протокола

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

Структура HTTP протокола

Структура HTTP протокола – словосочетание, не совсем точно описывающее то, о чем пойдет речь, правильнее было бы написать структура HTTP сообщения, но если к сообщению добавить HTTP соединение, то как раз получается цельная структура HTTP протокола. Итак, структура HTTP протокола очень простая – это сообщение плюс соединение. Сообщение обычно состоит из трех частей, которые передаются и клиентами, и серверами в следующем порядке:

  1. Стартовая строка или строка состояния, которая определяет тип HTTP сообщения. Стартовая строка обязательна для любого сообщения.
  2. Заголовок HTTP сообщения, который может включать одно поле Host или несколько полей для передачи различной служебной информации.
  3. Тело HTTP сообщения, которое содержит HTTP объекты. Тело сообщения служит для передачи пользовательской информации и есть не у каждого HTTP сообщения.

Терминология HTTP протокола

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

Параметры HTTP протокола

У HTTP протокола есть параметры, которые являются механизмом управления взаимодействия между клиентом и сервером. И которые определяют то, в каком виде информация будет передана по HTTP протоколу:

  1. Версия HTTP протокола является его обязательным параметром и указывается в первой строке любого HTTP сообщения.
  2. URI – это параметр, который позволяет однозначно идентифицировать ресурс, который хочет запросить клиент.
  3. Дата и время – это тоже параметр HTTP протокола.
  4. HTTP протокол имеет параметры кодирования сообщений и кодирования передачи.
  5. Тип данных или медиа тип – очередной параметр HTTP протокола.
  6. Лексемы программ позволяют определить разработчика HTTP приложения и версию приложения, а еще лексема является параметром HTTP протокола.
  7. HTTP протокол имеет параметры, которые позволяют определить язык сообщения, в HTTP это называется метка языка.
  8. А еще в HTTP есть единицы измерения диапазонов, которые позволяют запросить только часть ресурса.

Как происходит общение по протоколу HTTP: HTTP сообщение, HTTP запрос и HTTP ответ


Основной и единственной единицей измерения в HTTP протоколе является байт. Основным и единственным способом общения в HTTP протоколе является HTTP сообщение. Сообщения делятся на два вида: HTTP запрос – это сообщение, которое клиент посылает серверу и HTTP ответ – это сообщение, которое сервер посылает клиенту. В принципе, мы уже разобрались со структурой HTTP сообщения ранее, давайте теперь посмотрим примеры запросов и ответов в HTTP протоколе.

Давайте сначала посмотрим на то, что есть общего у любого сообщения в HTTP протоколе. Первое, что хочется выделить – это структура, она общая: статусная строка обязательна для всех сообщений, далее идет заголовок сообщения, в котором обязательное поле Host (в него записывается URI ресурса) и необязательное тело сообщения или, как его еще называют HTTP объект.

Статусная строка отделяется от заголовка символом CRLF в конце этой самой строки от HTTP заголовка (этот символ в Windows вы можете получить, нажав клавишу Enter – перенос строки), а HTTP заголовок отделяется от тела сообщения строкой, в которой только один символ – CRLF.

У запросов и ответов есть общие служебные заголовки, которые могут быть использованы, как при запросе, так и при ответе HTTP сервера. Так же хочу заметить, что есть группа заголовков относящихся к объектам (телу сообщения), они все могут быть использованы, как в запросах, так и в ответах, за исключением поля заголовка Allow, которое используется только в ответах сервера при взаимодействие по протоколу HTTP. У HTTP сообщения есть длина, которая измеряется в байтах, если у вашего HTTP сообщения есть тело, то для определения длины сообщения действуют следующие правила по порядку:

  1. Любое HTTP сообщение ответа сервера, которое не должно включать тело сообщения, всегда должно быть завершено пустой строкой после заголовков.
  2. Если в заголовках HTTP сообщений присутствует поле Transfer-Encoding (кодирование HTTP) при это у этого поля значение chunked, то длину HTTP сообщения следует определять методом кодирования по кускам (chunked encoding).
  3. Если у заголовка HTTP сообщения есть поле Content-Length, то значение, которое записано в Content-Length является длиной HTTP сообщения, измеряется в байтах.
  4. Если HTTP сообщение использует медиа типы «multipart/byteranges», который само разграничен, то он и определяет длину.
  5. Длина HTTP сообщения определяется закрытием соединения со стороны сервера.

Для ясности давайте рассмотрим примеры сообщений в HTTP протоколе и первое, что мы рассмотрим – пример запроса в HTTP протоколе:

Простой пример запроса в HTTP протоколе: сначала идет статусная строка, в которой мы указываем версию протокола HTTP и метод, который будет использован для обращения к ресурсу, а скрипт, находящийся по URL /cgi-bin/process.cgi будет использован для обработки данных. Статусная строка отделена символом CRLF в конце от заголовка, далее идет набор полей HTTP заголовка, которые отделяются друг от друга символом CRLF в конце строки. Если у одного поля есть несколько значений, то они отделяются друг от друга запятой. Тело сообщения отделено пустой строкой. Значение и описание всех полей заголовка HTTP протокола вы сможете найти на моем блоге в специальной записи: список полей HTTP заголовка.

А вот пример ответа в протоколе HTTP:

Синтаксис ответа в протоколе HTTP практически ничем не отличается, ключевым отличием является то, что в первой строке сервер посылает коды статуса, о которых мы поговорим чуть ниже.

Методы в HTTP протоколе

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

Методы в HTTP протоколе делятся на безопасные и идемпотентные. К безопасным относятся методы GET и HEAD, потому что они используются лишь для получения содержимого или его характеристик от сервера, а идемпотентные методы, это такие методы HTTP протокола, которые в случае своего многократного использования к ресурсу на одном и том же URI от одного и того же клиента будут давать такую же нагрузку, как будто этот метод выполнился только один раз, к идемпотентным методам HTTP протокола относятся: GET, HEAD, PUT, DELETE, OPTIONS и TRACE.

Давайте коротко рассмотрим методы HTTP протокола и их назначение:

  1. Метода GET в HTTP протоколе используется для получения информации от сервера по заданному URI. Запросы клиентов, использующие метод GET должны получать только данные и не должны никак влиять на эти данные.
  2. Метод HTTP протокола HEAD работает точно так же, как GET, но в ответ сервер посылает только заголовки и статусную строку без тела HTTP сообщения.
  3. Метод HTTP протокола POST используется для отправки данных на сервер, например, из HTML форм, которые заполняет посетитель сайта.
  4. Метода HTTP протокола PUT используется для загрузки содержимого запроса на указанный в этом же запросе URI.
  5. Метод HTTP протокола DELETE удаляет указанный в URI ресурс.
  6. Метод HTTP протокола CONNECT преобразует существующее соединение в тоннель.
  7. Метод HTTP протокола OPTIONS используется для получения параметров текущего HTTP соединения/.
  8. Метод HTTP протокола TRACE создает петлю, благодаря которой клиент может увидеть, что происходит с сообщением на всех узлах передачи.

Как происходит соединение по HTTP протоколу

На данный момент для каждого HTTP соединения HTTP протокол поддерживает постоянные TCP соединения, это означает, что при повторном запросе к серверу с одним и тем же IP-адресом, соединение четвертого уровня рваться не будет, а будет использовано существующее. Раньше это было не так и, если в HTML документе были картинки, то для загрузки каждой картинки использовалось новое соединение TCP/IP.

Обсуждение содержимого в HTTP протоколе

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

Прокол HTTP имеет два вида обсуждения: обсуждение, управляемое сервером и обсуждение, управляемое клиентом. Стоит отметить, что эти два вида обсуждения HTTP независимы друг от друга и могут использоваться вместе.

Коды состояния в HTTP протоколе

Коды состояния в HTTP протоколе говорят клиенту о том, что произошло с его запросом, как сервер понял запрос и нужно ли делать что-нибудь клиенту, чтобы запрос был выполнен корректно. Коды состояния – это три цифры, например, 100, 301, 404, 503. Коды состояния в HTTP протоколе делятся на пять классов состояния: информационные коды (они начинаются с единицы), успешные коды (начинаются с двойки), коды перенаправления (начинаются с тройки), коды ошибок клиента (начинаются с четверки), коды ошибок сервера (начинаются с пятерки). Ниже приведена таблица классов кодов состояния их короткое описание. А еще вы можете посмотреть справочник кодов состояния.

Номер Класс кода состояния в HTTP протоколе и его описание
1 HTTP коды состояний 1xx: информационные

Такой код состояния сервер высылает в том случае, когда запрос получен, но еще не обработан.

2 HTTP коды состояний 2xx: успешные

Сервер отправит вам такой код в том случае, когда он успешно принял и обработал HTTP сообщение клиента.

3 HTTP коды состояний 3xx: перенаправление

Если вы получили от сервера код состояния, начинающийся на тройку, то это означает, что нужны дополнительные действия, чтобы завершить процесс обработки HTTP запроса.

4 HTTP коды состояний 4xx: ошибка клиента

Если вы увидели код состояния, который начинается с четверки, то это означает, что произошла ошибка по вине клиента.

5 HTTP коды состояний 5xx: серверная ошибка

Код состояния, начинающийся с пятерки, говорит о том, что произошла ошибка на стороне сервера.

Поля заголовка HTTP сообщения

В протоколе HTTP есть поля заголовка, которые позволяют настроить взаимодействие между клиентом и сервером, а так же то, как и в каком виде полезную информацию будет получать конечный пользователь. Общий синтаксис полей заголовка довольно прост:

Поля заголовка разделяются между собой символом CRLF. HTTP протокол делит поля заголовка на четыре группы:

  1. Общие поля заголовка. Такие заголовки могут быть использованы в любых сообщениях, передаваемых по HTTP протоколу.
  2. Поля заголовка запросов. Эти сообщения могут быть переданы только в запросах HTTP протокола.
  3. Поля заголовка ответов. Как понятно из названия, эти поля используются только при HTTP ответах.
  4. Поля заголовка тело сообщения. А эти поля используются тогда, когда необходимо определить, как и в каком виде будет представлена информация конечному пользователю, которая передается по HTTP.

Более подробно о полях заголовков HTTP сообщения смотрите справочник полей заголовка HTTP сообщения.

Кэширование HTTP протокола

С целью уменьшения нагрузки на сеть и повышения эффективности HTTP протокола был реализован механизм кэширования. Зачастую бывает так, что пользователь даже не догадывается о том, что страница, открытая в его браузере, подгрузилась не с сайта, к которому он обращался, а из кэша. Мы не будем вдаваться во внутренние механизмы кэширования того или иного сервера/клиента, а лишь посмотрим, что есть непосредственно у протокола HTTP для управления кэшированием. И, как вы наверное уже догадались, в HTTP протоколе кэшированием управляют поля заголовка и директивы, то есть значения этих самых полей.

Отмечу, что HTTP протокол реализован так, что этим директивам должны следовать все участники цепочки между клиентом и конечным сервером. Директивы условном можно поделить на клиентские и серверные. Давайте посмотрим на директивы HTTP протокола, предназначенные для управления кэшированием со стороны клиента.

Номер Директивы поля заголовка Cache Control для клиента и их описание
1 no cache

Директива HTTP протокола no-cache говорит серверу о том, что для последующего запроса ответ не должен отправляться из кэша без проверки с содержимым исходного сервера.

2 no store

Директива HTTP протокола no-store говорит серверу о том, что ни запрос клиента, ни ответ сервера не должны кэшироваться. Это сделано для безопасности.

3 max age = seconds

Директива HTTP протокола max-age говорит серверу о том, что кэш должен быть не старше времени, которое указано в секундах.

4 max stale [ = seconds ]

Директива HTTP протокола max-stale говорит серверу о том, что клиент примет кэшированный HTTP ответ в том случае, если его возраст не превышает времени, указанного в секундах.

5 min fresh = seconds

Директива HTTP протокола min-fresh говорит серверу о том, что клиент примет кэшированный HTTP ответ в том случае, если время жизни кэша не больше указанных секунд.

6 Директива HTTP протокола min-fresh говорит серверу о том, что к запрашиваемому ресурсу не должно применяться никаких преобразований.
7 only if cached
Директива HTTP протокола min-fresh говорит серверу о том, что клиент примет только кэшированный HTTP ответ, если подходящего ответа нет в кэше сервера, то делать ничего не надо.
Номер Директивы поля заголовка Cache Control для сервера и их описание
1 public

Директива HTTP протокола Public говорит о том, что ответ сервера можно сохранять в любом кэше.

2 private

Директива HTTP протокола private говорит о том, что ответ сервера нужно сохранять в закрытом кэше, который предназначен только для этого пользователя.

3 no cache

Директива HTTP протокола no cache говорит о том, что кэшированный ответ не должен отправляться клиенту без его предварительной проверки.

4 no store

Директива HTTP протокола no store говорит о том, что ответ сервера нельзя сохранять в кэше.

5 no transform

Директива HTTP протокола no transform говорит о том, что к ответу сервера не должно применяться никаких преобразований ни одним из узлов цепочки.

6 must revalidate

Директива HTTP протокола must revalidate говорит о том, что если HTTP сообщение сервера устарело, то к нему должна применяться предварительная проверка.

7 proxy revalidate

Директива HTTP протокола proxy revalidate говорит о том, что и предыдущая директива, но только для промежуточных серверов.

8 max age = seconds

Директива HTTP протокола max age говорит о том, сколько живет кэш на сервере.

9 Директива поля заголовка Cache Control ответа сервера: s maxage = seconds

Директива ответа сервера Public говорит о том, что и директива max-age, но для CDN-серверов

И клиентские, и серверные HTTP приложения должны уметь сравнивать данные из кэша, чтобы не гонять по сети лишний трафик и при этом конечный пользователь на свои запросы получал актуальную информацию. С этой целью в HTTP протокол было введено специальное поле Last-Modified и условные метода запроса с условными полям заголовка. В поле Last-Modified указывается дата и время создания кэшированной версии, значение этого поля может сравнивается со значением даты времени того момента, когда произошло последнее обновление оригинального ресурса и если значения совпадают, то данные клиенту поступают из кэша.

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

А еще HTTP протокол позволяет присваивать каждому HTTP объекту тэг в поле заголовка ETag, по сути, это хэш сумма самого объекта и для каждого неповторяющегося объекта она уникальная, поэтому механизм кэширования HTTP протокола активно использует данное поле для проверки актуальности данных, которые хранятся в кэше.


Безопасность HTTP протокола

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

Но у HTTP протокола есть расширение HTTPS, обратите внимание HTTPS – это не протокол, а расширение HTTP протокола, которое использует TCP порт 433. Это расширение является связкой двух протоколов: HTTP и SSL или HTTP и TLS (TLS и SSL, суть одно и то же).

Http сообщение / rfc 2068

29 просмотра

2 ответа

35 Репутация автора

Кроме того, распространение не полностью реализованных
приложений, называющих себя «HTTP / 1.0», потребовало
изменения версии протокола, чтобы два взаимодействующих приложения
могли определить истинные возможности друг друга.

Ответы (2)

1 плюс

816 Репутация автора

С человеческой точки зрения, они говорят: так много людей сказали, что они сделали HTTP 1.0, а они нет, что никто не знал, действительно ли это был HTTP 1.0, когда кто-то сказал это.

Чтобы выбраться из этого, они выбрали новый номер.

2 плюса

77043 Репутация автора

HTTP используется Глобальной информационной инициативой Всемирной паутины с 1990 года. Первая версия HTTP, называемая HTTP / 0.9, была простым протоколом для передачи необработанных данных через Интернет.

До стандартизации HTTP существовали различия в реализациях, которые означали, что они не всегда могли правильно общаться друг с другом (например, некоторые веб-браузеры не могли работать с определенными веб-серверами). Статья RFC ссылается на эти реализации предварительной стандартизации как на использование HTTP/0.9 .

HTTP / 1.0, как определено в RFC 1945, улучшил протокол, позволив сообщениям быть в формате MIME-подобных сообщений, содержащих метаинформацию о передаваемых данных и модификаторы в семантике запрос / ответ. Однако HTTP / 1.0 недостаточно учитывает эффекты иерархических прокси, кэширования, необходимости постоянных соединений и виртуальных хостов. Кроме того, распространение не полностью реализованных приложений, называющих себя «HTTP / 1.0», потребовало изменения версии протокола, чтобы два взаимодействующих приложения могли определить истинные возможности друг друга.

После того, как HTTP был стандартизирован, HTTP/1.0 это, безусловно, помогло решить проблемы совместимости и совместимости, но версия 1.0 протокола просто предполагала, что все программное обеспечение HTTP сможет использовать его для своего существующего приложения, но теперь это HTTP/1.0 уже некоторое время используется сопровождающими. Спецификация протокола HTTP показала, что им необходимо расширить HTTP для поддержки этих вариантов использования (например, прокси-серверы, кэши, постоянные соединения, виртуальные хосты), и хотя эти вещи можно было сделать с помощью встроенных механизмов расширения, поскольку HTTP/1.0 они чувствовали необходимость увеличения номер версии HTTP/1.1 , чтобы предотвратить реализацию, просто предполагая, что удаленный хост поддерживает функцию или нет.

пример

Хорошим примером является Host заголовок, HTTP/1.1 который позволяет веб-серверу, обслуживающему один IP-адрес и номер порта, обслуживать разные веб-сайты на основе Host заголовка (как и раньше HTTP/1.1 существующие веб-серверы могли обслуживать только один веб-сайт на IP-адрес, что является проблема). HTTP/1.0 позволяет клиентам и серверам добавлять свои собственные пользовательские заголовки, например Host , однако у клиента или сервера нет возможности узнать, что другой конец фактически поддерживает Host заголовок. Но в HTTP/1.1 в Host заголовке ранее был добавлен в спецификации , так что если клиент и сервер заявляют , что они используют , HTTP/1.1 то другой конец знает , что они признают Host заголовок и обрабатывать его правильно.

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

HTTP (Hypertext Transfer Protocol)

HTTP
Уровень (по модели OSI): Прикладной
Семейство: стек протоколов TCP/IP
Порт/ID: 80/TCP
Спецификация: RFC 1945, RFC 2616
Основные реализации (клиенты): Веб-браузеры, например Internet Explorer, Mozilla Firefox, Opera, Google Chrome и др.
Основные реализации (серверы): Apache HTTP Server
Вступил в силу с: 1992

HTTP (англ. HyperText Transfer Protocol — «протокол передачи гипертекста») — сетевой протокол прикладного уровня передачи данных. Протокол основан на технологии «клиент-сервер», то есть предполагается существование потребителей (клиентов), которые инициируют соединение и посылают запрос, и поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом.

HTTP используется в других протоколах прикладного уровня, а также для передачи с сервера на клиент любых объектов: картинок, скриптов, CSS-файлов, файлов данных. Также он работает и в обратную сторону — для заливки на сервер файлов, отправки форм и т.п. AJAX-приложения также, очевидно, общаются с сервером по HTTP. Иногда HTTP используется и для более специфических вещей, например, для управления содержимым сервера по протоколу WebDAV, XML-RPC, WebDAV.

Существуют протоколы, аналогичные HTTP, такие как FTP и SMTP. Чтобы идентифицировать ресурсы HTTP протокол использует глобальные URL. HTTP не сохраняет своего состояния между парами «запрос-ответ». Компоненты HTTP могут сохранять информацию. Например, со стороны клиента сохраняются «куки», а на стороне сервера «сессии». Браузер, в свою очередь, может отслеживать задержки ответов, а сервер хранит IP-адреса запросов клиентов.

Содержание

История

Параметры протокола

HTTP сообщение

Сообщения HTTP включают в себя запросы клиента к серверу и отклики сервера клиенту.

Сообщения запрос и отклик используют общий формат сообщений RFC-822 для передачи объектов (поле данных сообщения). Оба типа сообщений состоят из стартовой строки, одного или более полей заголовка (также известные как «заголовки»), пустой строки (то есть, строка, содержащая CRLF), отмечающей конец полей заголовка, а также опционного тела сообщения.

В интересах надежности, рекомендуется серверам игнорировать любые пустые строки, полученные, когда ожидается Request-Line (строка запроса). Другими словами, если сервер читает протокольный поток в начале сообщения и получает сначала CRLF, он должен игнорировать CRLF.

Методы

Метод HTTP (англ. HTTP Method ) — последовательность из любых символов, кроме управляющих и разделителей, указывающая на основную операцию над ресурсом. Обычно метод представляет собой короткое английское слово, записанное заглавными буквами. Обратите внимание, что название метода чувствительно к регистру.

Каждый сервер обязан поддерживать как минимум методы GET и HEAD . Если сервер не распознал указанный клиентом метод, то он должен вернуть статус 501 (Not Implemented). Если серверу метод известен, но он неприменим к конкретному ресурсу, то возвращается сообщение с кодом 405 (Method Not Allowed). В обоих случаях серверу следует включить в сообщение ответа заголовок Allow со списком поддерживаемых методов.

Кроме методов GET и HEAD , часто применяется метод POST .

Семантика метода меняется на «условный GET», если сообщение-запрос включает в себя поля заголовка If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match или If-Range. Метод условного GET запрашивает, пересылку объекта только при выполнении требований, описанных в соответствующих полях заголовка. Метод условного GET имеет целью уменьшить ненужное использование сети путем разрешения актуализации кэшированых объектов без посылки множественных запросов или пересылки данных, которые уже имеются у клиента. Семантика метода GET меняется на «частичный GET», если сообщение запроса включает в себя поле заголовка Range. Запросы частичного GET, которые предназначены для пересылки лишь части объекта. Метод частичного GET ориентирован на уменьшение ненужного сетевого обмена, допуская пересылку лишь части объекта, которая нужна клиенту, и не пересылая уже имеющихся частей.

Метод HEAD идентичен GET за исключением того, что сервер не должен присылать тело сообщения. Метаинформация, содержащаяся в заголовках отклика на запрос HEAD должна быть идентичной информации посланной в отклик на запрос GET. Этот метод может использоваться для получения метаинформации об объекте, указанном в запросе, без передачи тела самого объекта. Этот метод часто используется для тестирования гипертекстных связей на корректность, доступность и актуальность.

Метод PUT требует, чтобы вложенный объект был запомнен с использованием Request-URI. Если Request-URI относится к уже существующему ресурсу, то вложенный объект следует рассматривать как модифицированную версию объекта на исходном сервере. Если Request-URI не указывает на существующий ресурс и запрашивающий агент пользователя может определить этот URI как новый ресурс, исходный сервер может создать ресурс с этим URI. Если новый ресурс создан, исходный сервер должен информировать об этом агента пользователя, послав код отклик 200 (OK) или 204 (No Content — никакого содержимого) и тем самым, объявляя об успешно выполненном запросе. Если ресурс не может быть создан или модифицирован с помощью Request-URI, должен быть послан соответствующий код отклика, который отражает характер проблемы. Получатель объекта не должен игнорировать любой заголовок Content-* (например, Content-Range), который он не понял или не использовал, а должен в таком случае вернуть код отклика 501 (Not Implemented — не использовано).

Метод POST используется при заявке серверу принять вложенный в запрос объект в качестве нового вторичного ресурса, идентифицированного Request-URI в Request-Line. POST создан для обеспечения однородной схемы реализации следующих функций:

  • Аннотация существующего ресурса;
  • Помещение сообщения на электронную доску объявлений, в группу новостей, почтовый список или какую-то другую группу статей;
  • Выдача блока данных, такого как при передаче формы процессу ее обработки;

Расширение базы данных с помощью операции добавления (append).

DELETE

Метод DELETE требует, чтобы исходный сервер уничтожил ресурс, идентифицируемый Request-URI.

TRACE

Метод TRACE используется для того, чтобы запустить удаленный цикл сообщения-запроса на прикладном уровне. Конечный получатель запроса должен отослать полученное сообщение назад клиенту в виде тела объекта (код = 200 (OK)). Конечным получателем является либо исходный сервер, либо первый прокси или шлюз для получения значения Max-Forwards (0) в запросе. Запрос TRACE не должен включать в себя объект.

Коды состояния

Определенные некорректные реализации HTTP/1.0 клиентов генерируют дополнительные CRLF после запроса POST. Клиент HTTP/1.1 не должен посылать CRLF до или после запроса.

Диалог HTTP

Список кодов состояния HTTP#1xx|1xx Informational («Информационный»)

В этот класс выделены коды, информирующие о процессе передачи. В HTTP/1.0 сообщения с такими кодами должны игнорироваться. В HTTP/1.1 клиент должен быть готов принять этот класс сообщений как обычный ответ, но ничего отправлять серверу не нужно. Сами сообщения от сервера содержат только стартовую строку ответа и, если требуется, несколько специфичных для ответа полей заголовка. Прокси-серверы подобные сообщения должны отправлять дальше от сервера к клиенту.

Список кодов состояния HTTP#2xx|2xx Success («Успех»)

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

Список кодов состояния HTTP#3xx|3xx Redirection («Перенаправление»)


Коды класса 3xx сообщают клиенту что для успешного выполнения операции необходимо сделать другой запрос (как правило по другому URI). Из данного класса пять кодов Список кодов состояния #301|301 , Список кодов состояния HTTP#302|302 , Список кодов состояния HTTP#303|303 , Список кодов состояния HTTP#305|305 и Список кодов состояния #307|307 относятся непосредственно к перенаправлениям (редирект). Адрес, по которому клиенту следует произвести запрос, сервер указывает в заголовке Location . При этом допускается использование фрагментов в целевом URI.

Список кодов состояния HTTP#4xx|4xx Client Error («Ошибка клиента»)

Класс кодов 4xx предназначен для указания ошибок со стороны клиента. При использовании всех методов, кроме HEAD , сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.

Список кодов состояния HTTP#5xx|5xx Server Error («Ошибка сервера»)

Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера. Для всех ситуаций, кроме использования метода HEAD , сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю.

Код Ошибка Описание
300 Множественный выбор Затребованный URL обозначает более одного ресурса, и робот не смог однозначно определить, к какой странице URL относится (получен код 300 Multiple Choices).
301 Ресурс перемещен навсегда Документ уже не используется сервером, а ссылка перенаправляет на другую страницу (получен код 301 Moved Permanently).
307 Временное перенаправление Затребованный ресурс был временно переведен на другой адрес, который необходимо прописать в Location (получен код 307 Temporary Redirect).
400 Неверный запрос Запрос не может быть понят сервером из-за некорректного синтаксиса (получен код 400 Bad Request).
403 Доступ к ресурсу запрещен Доступ к документу запрещен (получен код 403 Forbidden). Если вы хотите, чтобы страница индексировалась, необходимо разрешить доступ к ней.
404 Ресурс не найден Документ не существует (получен код 404 Not Found).
410 Ресурс недоступен Затребованный ресурс был окончательно удален с сайта (получен код 410 Gone).
412 Сбой при обработке предварительного условия При проверке на сервере одного или более полей заголовка запроса обнаружено несоответствие (сбой или ошибка при обработке предварительного условия).
417 Сбой при ожидании Сервер отказывается обрабатывать запрос, потому что значение поля Expect в заголовке запроса не соответствует ожиданиям (получен код 417 Expectation Failed).
423 Заблокировано Сервер отказывается обработать запрос, так как один из требуемых ресурсов заблокирован (получен код 423 Locke).
500 Внутренняя ошибка сервера Сервер столкнулся с непредвиденным условием, которое не позволяет ему выполнить запрос (получен код 500 Internal Server Error).
502 Ошибка шлюза Сервер, действуя в качестве шлюза или прокси-сервера, получил недопустимый ответ от следующего сервера в цепочке запросов, к которому обратился при попытке выполнить запрос
505 Версия HTTP не поддерживается Сервер не поддерживает или отказывается поддерживать версию HTTP-протокола, которая используется в сообщении запроса робота (получен код 505 HTTP Version Not Supported).

Структура протокола

Запрос

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

Отклик

После получения и интерпретации сообщения-запроса, сервер реагирует, посылая HTTP сообщение отклик.

Отправив HTTP-запрос серверу, клиент ожидает ответа. HTTP-ответ выглядит в целом аналогично запросу: статусная строка, список заголовков и тело ответа.

Объект и соединение

Сообщения запрос и отклик могут нести в себе объект, если это не запрещено методом запроса или статусным кодом отклика. Объект состоит из полей заголовка объекта и тела объекта, хотя некоторые отклики включают в себя только заголовки объектов. В данном разделе, как отправитель, так и получатель соотносятся к клиенту или серверу, в зависимости от того, кто отправляет и кто получает объект.

Постоянное HTTP соединение имеет много преимуществ:

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

Клиенты

Первоначально протокол HTTP разрабатывался для доступа к гипертекстовым документам Всемирной паутины. Поэтому основными реализациями клиентов являются браузеры (агенты пользователя). Для просмотра сохранённого содержимого сайтов на компьютере без соединения с Интернетом были придуманы офлайн-браузеры. При нестабильном соединении для загрузки больших файлов используются Менеджеры закачек. Они позволяют в любое время докачать указанные файлы после потери соединения с веб-сервером. Виртуальные атласы тоже используют HTTP.

Исходные серверы

Apache HTTP ServerApache, Internet Information Services (IIS), nginx, Google Web Server, lighttpd.

Прокси-серверы

Squid, UserGate, Multiproxy, Naviscope, nginx.

Оптимизация

Оптимизация с помощью HTTP keep-alive

Протокол HTTP работает поверх протокола TCP («Transmission Control Protocol»). TCP — это надёжный протокол двусторонней передачи потока данных. TCP работает, пересылая пакеты данных от клиента к серверу и обратно. TCP-пакет состоит из заголовка и данных. В заголовке указаны, помимо прочего, IP-адреса клиента и сервера, номера TCP-портов, используемых на клиенте и сервере, и набор флагов. Для HTTP на сервере обычно используется стандартный TCP-порт номер 80.

TCP-соединение между клиентом и сервером устанавливается с помощью классического «TCP three-way handshake». Сначала клиент посылает серверу пакет с флагом SYN. В ответ сервер посылает пакет с флагами SYN+ACK. Наконец, клиент посылает ещё один пакет, с флагом ACK и с этой минуты соединение считается установленным, и клиент может посылать свои данные, в нашем случае — HTTP-запрос. Понятно, что если десяток тысяч браузеров установит с сервером keep-alive соединение, то они достаточно быстро исчерпают его ресурсы. Поэтому во всех серверах есть конфигурируемый тайм-аут, по истечении которого keep-alive соединение разрывается, если на нём не было никакой активности.

Клиент может запросить разрыв соединения после ответа, передав в запросе заголовок Connection: close. Аналогично, сервер может сообщить в ответе, что не желает поддерживать keep-alive соединение, передав точно такой же заголовок: Connection: close. Вообще говоря, все эти расшаркивания с взаимным уведомлением, строго говоря, не налагают никаких обязанностей. И сервер, и клиент должны быть полностью готовы к тому, что соединение прервётся в любой момент времени по инициативе другой стороны без каких-либо уведомлений.

Для того, чтобы соблюсти целостность keep-alive соединения, сервер должен знать длину ответа. Самый простой способ — указать её в заголовке Content-Length. Если длина ответа не указана обработчиком, то сервер вынужден перед отправкой ответа установить заголовок Connection: close и закрыть соединение со своей стороны после отправки ответа.

Оптимизация с помощью компрессии

Прекрасным способом существенно снизить трафик и ускорить отклик сервера является компрессия отдаваемых файлов и страниц. Практически все современные веб-сервера так или иначе поддерживают эту функциональность. Коэффициент сжатия варьируется в зависимости от каждой конкретной страницы и может достигать значений порядка 10. Для разработчика веб-приложения сжатие полностью прозрачно и не требует никаких усилий.

Способность принимать компрессированное содержимое клиент анонсирует серверу с помощью заголовка Accept-Encoding: gzip. Если сервер настроен на сжатие соответствующего контента, то он может добавить заголовок ответа Content-Encoding: gzip (не путать с Transfer-Encoding) и отправить клиенту сжатое содержимое.

Оптимизация с помощью HTTP-pipelining

Когда мы делаем серию запросов и ответов в рамках одного keep-alive соединения, важную роль в производительности играет время задержки (latency) между запросом и ответом. Задержка может быть вызвана как высокой задержкой на канале, так и большим временем обработки запросов на сервере. Перед посылкой очередного запроса мы должны дождаться завершения обработки следующего. Чтобы справиться с этой проблемой, может использоваться технология HTTP-pipelining.

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

Обеспечение безопасности

Базовая схема идентификации не предоставляет безопасного метода идентификации пользователя, не обеспечивает она и каких-либо средств защиты объектов, которые передаются открытым текстом по используемым физическим сетям. HTTP не мешает внедрению дополнительных схем идентификации и механизмов шифрования или других мер, улучшающих безопасность системы (например, SSL или одноразовых паролей). Наиболее серьезным дефектом базового механизма идентификации в HTTP является то, что пароль пользователя передается по сети в незашифрованном виде.

Аутентификация клиентов

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

Передача конфиденциальной информации

Подобно любому общему протоколу передачи данных, HTTP не может регулировать содержимое передаваемых данных, не существует методов определения степени конфиденциальности конкретного фрагмента данных в пределах контекста запроса. Следовательно, приложения должны предоставлять как можно больше контроля провайдеру информации. Четыре поля заголовка представляют интерес с точки зрения сохранения конфиденциальности: Server, Via, Referer и From. Раскрытие версии программного обеспечения сервера может привести к большей уязвимости машины сервера к атакам на программы с известными слабостями. Разработчики должны сделать поле заголовка Server конфигурируемой опцией. Прокси, которые служат в качестве сетевого firewall, должны предпринимать специальные предосторожности в отношении передачи информации заголовков, идентифицирующей ЭВМ, за пределы firewall.

Персональная информация

Клиентам HTTP небезразличнен доступ к некоторым данным (например, к имени пользователя, IP-адресу, почтовому адресу, паролю, ключу шифрования и т.д.). Система должна быть тщательно сконструирована, чтобы предотвратить непреднамеренную утечку информации через протокол HTTP. Мы настоятельно рекомендуем, чтобы был создан удобный интерфейс для обеспечения пользователя возможностями управления распространением такой информации.

Что означает эта линия в rfc2068

Кроме того, распространение не полностью реализованных
приложения, называющие себя «HTTP/1.0», потребовали
изменение версии протокола для двух коммуникационных приложений
для определения истинных возможностей друг друга.

HTTP используется глобальной информационной инициативой World Wide Web с 1990 года. Первая версия HTTP, называемая HTTP/0.9, была простым протоколом для передачи необработанных данных через Интернет.

До того, как был стандартизирован HTTP, различия в реализациях означали, что они не всегда могли правильно общаться друг с другом (например, некоторые веб-браузеры не могли работать с определенными веб-серверами). Статья RFC ссылается на эти реализации до стандартизации, используя HTTP/0.9 .

HTTP/1.0, как определено RFC 1945, улучшил протокол, разрешив сообщения в формате MIME-подобных сообщений, содержащих метаинформацию о переданных данных и модификаторах в семантике запроса/ответа. Однако HTTP/1.0 недостаточно учитывает эффекты иерархических прокси-серверов, кеширования, необходимости постоянных соединений и виртуальных хостов. Кроме того, распространение не полностью реализованных приложений, называющих себя «HTTP/1.0», потребовало изменения версии протокола, чтобы два коммуникационных приложения определяли друг друга истинными возможностями.

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

пример

Хорошим примером является Host — заголовок HTTP/1.1 , который позволяет для веб-сервера, служащего из одного IP — адреса и номера порта, чтобы служить вверх различных веб — сайтов на основе Host заголовка (как перед HTTP/1.1 существовали веб — серверы могут служить только один сайт на IP-адрес, что является проблемой). HTTP/1.0 позволяет клиентам и серверам добавлять свои собственные пользовательские заголовки, такие как Host , однако для клиента или сервера нет возможности узнать, что другой конец фактически поддерживает заголовок Host . Но в HTTP/1.1 заголовок Host ранее был добавлен в спецификацию, поэтому, если оба клиента и сервер объявляют, что они используют HTTP/1.1 то другой конец знает, что они узнают заголовок Host и обрабатывают его правильно.

RFC 2068 дополненная БНФ

Я пытаюсь разобрать заголовки запроса авторизации, см. Https://www.ietf.org/rfc/rfc2617.txt раздел 3.2.2. Там дайджест-ответ определяется следующим образом:

Используемый здесь расширенный BNF определен в http://www.ietf.org/rfc/rfc2068.txt , раздел 2.1.

Если я прав, дайджест-ответ — это (по приведенному выше определению) список, по крайней мере, из одного элемента, каждый из которых разделен одной или несколькими запятыми и необязательным линейным пробелом.

У меня есть несколько вопросов относительно определения дайджест-ответа:

1) Является ли следующий дайджест-ответ действительным (если нет, то почему)? username_1, username_2


2) Допустим ли следующий дайджест-ответ (если нет, то почему)? имя пользователя, область, nonce, дайджест-URI

3) Является ли следующий дайджест-ответ действительным (если нет, то почему)? username_1, realm, nonce, digest-uri, ответ, username_2

4) Как выглядят возможные произведения для 1 # (a | b) и 1 # (a | [b]), и в чем разница?

Протокол HTTP

Протокол HTTP используется в World Wide Web (WWW) начиная с 1990 года. Его версия описана 1.0 в RFC 1945, версия 1.1 в RFC 2068/

Все HTTP-транзакции имеют один общий формат. Каждый запрос клиента и ответ сервера состоит из строки запроса (ответа), сопровождаемой вспомогательными строками заголовка и тела. Строки заголовка отделяются друг от друга парой символов . Тело отделяется от заголовков пустой строкой. Заголовки могут быть любой длины, и сервер обязан либо обработать длинный заголовок, либо выдать соответствующий код ошибки. Тело запроса (ответа) представляет последовательность байтов, на которую не накладывается никаких ограничений.

Клиент устанавливает связь с сервером по назначенному номеру порта (по умолчанию — 80)., и, не дожидаясь никакой реакции от сервера, посылает запрос, указав HTTP-команду, называемую методом, адрес документа и номер версии HTTP. Например:

В примере используется метод GET, которым с помощью версии 1.0 HTTP запрашивается документ index.html с виртуального сервера www.example.com.

Послав запрос и заголовки, клиент может отправить дополнительные данные. Эти данные используются главным с методом POST для передачи .

Сервер отвечает на запрос клиента следующим образом:

Первая часть строка ответа сервера — строка состояния, содержащая три поля: версию HTTP, числовой код ответа и текстовое описание этого кода.

После заголовка отправляются затребованные данные. Если запрос клиента удовлетворить нельзя, передается сообщение об ошибке в приемлемом для чтения человеком виде.

HTTP не сохраняет информацию по транзакциям, каждая пара запрос-ответ проводится независимо, даже в рамках одного TCP соединения.

Методы

Метод — это HTTP-команда, с которой начинается первая строка запроса клиента.Реально используются GET, HEAD и POST. При задании имен методов учитывается регистр, поэтому GET и get различаются.

Приведенные ниже методы определены, но практически не используются:

Метод GET

GET — это запрос к серверу, который ничего не изменяет на сервере, например, выполняет считывание записи из БД.

В URL кодируются параметры запроса. Сначала идут позиционные параметры, разделенные знаком ‘/’, а затем, после символа ‘&’ — именованные в виде пар ключ-значение. Пары отделяются друг от друга амперсандом ‘&’. Например:

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

Хотя позиционные параметры могут выглядеть, как имена каталогов и файлов, реальная интерпретация зависит от реализации на стороне сервера. Например, следующая запись может означать запуск скрипта /cgi-bin/display.pl для вывода файла /text/doc.txt (а может и не означать):

Метод POST

Метод POST это запрос к серверу, который изменяет состояние сервера, например вносит запись в БД.

Параметры запроса в методе POST могут передаваться в теле запроса. В этом случае их общая длина ничем не ограничена.

Метод HEAD

Метод HEAD аналогичен методу GET, за исключением того, что сервер ничего не посылает в информационной части ответа. Метод HEAD запрашивает только информацию заголовка о файле или ресурсе. Этот метод используется, когда клиент хочет получить информацию о документе, не получая его. Например, клиента может интересовать:

  • время изменения документа;
  • размер документа;
  • тип документа;
  • тип сервера.

Некоторые заголовки не являются обязательными и могут отсутствовать в ответе сервера.

Авторизация

Если ресурс требует авторизации пользователя, то сервер в ответ на запрос может вернуть код ответа 401 Unauthorized и строку заголовка с указанием области доступа для которой требуется авторизация

Чтобы получить права доступа, клиент посылает в последующих запросах идентификатор пользователя и пароль, разделенные символом двоеточия «:». Строка авторизации кодируется в base64.

В реальной жизни используется тип авторизации Basic и NTLM.

Заголовки запроса

В запросе клиент должен передать URI запрашиваемого документа. Это может быть сделано в абсолютной или относительной форме. В первом случае в состав URI должны входить название протокола и имя сервера.

Во втором случае передается только путь к документу.

В этом случае имя и порт хоста, может быть передано в строке заголовка Host:

Наличие имени хоста необходимо для обращений к прокси-серверу, или для обращения к одному из виртуальных хостов размещенных на одном сервере. Если хост, заданный одним из двух способов, не существует, то сервер возвращает ответ 400- Bad Request.

Поля заголовка запроса позволяют клиенту передавать серверу дополнительную информацию о запросе и о самом клиенте.

Передача данных в ответе сервера

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

Content-Type: Тип сообщения, аналогичен типу содержимого в стандарте MIME и указывается в формате тип/подтип.

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

В типе сообщения для текстовых форматов может быть указана использованная кодировка.

Content-Encoding: Для 8 битового протокола HTTP, данный заголовок означает, что данные дополнительно закодированы, например сжаты. Определены три типа кодирования gzip, compress, deflate, что соответствует форматам программ gzip, compress и библиотеки zlib. Например:

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

Content-Length: Длина тела сообщения. В протоколе HTTP/1.0 это была единственная возможность передать клиенту информацию о размере данных.

Кодирование данных кусками (chunced) было введено в HTTP/1.1. В заголовках ответа должна присутствовать строка

А тело сообщения строится по следующим правилам

Признаком завершения передачи является кусок нулевой длины.

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

Еще одной возможностью для кодирования данных является использование для тела сообщения типа multipart/bytranges – эквивалентного MIME multipart/*

Если размер сообщения не указан, не используется кодирование кусками и тип тела сообщения не multipart/bytranges, то клиент определяет конец тела ответа по закрытию TCP соединения.

Bog BOS: Формат сообщений интернет (от RFC822 к RFC2822)

Базовый формат почтовых сообщений (писем, messages) и статей USENET (article) определяется RFC 822 и его «наследником» RFC 2822. Каждое сообщение (письмо, message, статья, article) состоит из конверта и содержимого. Конверт хранит адресную информацию, необходимую для отправки и передачи сообщения получателю. Формат конверта определяется средой распространения. Для его автоматического создания может использоваться информация из содержимого сообщения. Стандарт определяет только формат содержимого сообщения и только в момент передачи, т.е. сообщения могут храниться совершенно в другом формате (например, в БД). RFC 1123 определяет, что MTA должен уметь обрабатывать сообщения размером до 64 КБ (но желательно и больше),

Сообщение делится на строки и состоит из секции заголовков и тела сообщения (возможно пустого). Формат тела сообщения не определяется, лишь говорится, что оно состоит из строк ASCII, точнее ANSI X3.4 (7-битные символы!), отделенных от секции заголовков пустой строкой (CRLF), которая должна присутствовать даже для пустого тела (чтобы отличить его от ошибочного сообщения с порезанным заголовком). Следует заметить, что хотя формат тела не определен, но передавать двоичные данные все же не следует, так как предполагается, что оно делится на строки, а символы конца строки могут модифицироваться при передаче в подсеть или при хранении. Существуют также правила «хорошего тона»: при цитировании предыдущего письма, цитируемый текст предваряется знаком «>» (без пробела!); перед подписью вставляется строка «— » (обратите внимание на пробел перед концм строки!). Длина строки должна быть не более 998 символов, но желательно не порождать строк длиной более 78 символов (не считая CRLF).

Заголовок делится на поля, некоторые из которых являются обязательными (Date и хотя бы одно из полей, описывающих отправителя: From, Sender, Reply-To). Опциональные поля описываются, но не являются обязательными. Можно добавлять свои поля (начинаются с X-). Порядок полей несущественен, но запрещено менять порядок полей Received и Resent-. Последствия присутствия нескольких полей с одинаковым именем непредсказуемы (явно запрещены для всех стандартизованных полей, кроме Comment, Keywords, Received и Resent-), кроме полей To, Cc и Bcc (содержимое соответствующих полей сливается). Поле занимает одну логическую строку и состоит из имени поля (символы от 0x21 до 0x7e, кроме двоеточия), двоеточия и тела поля (ASCII, кроме CR и LF; опять-таки только 7-битные символы!). Тело поля может быть разбито на несколько строк путем вставки CRLF перед пробельным символом (пробел или табуляция).


Тело поля может быть неструктурировано (строка текста) или структурировано. Структурированное тело поля состоит из специальных символов (круглые, угловые или квадратные скобки, @, точка, запятая, двоеточие, точка с запятой, обратная косая черта, кавычки), пробельных символов, строк в кавычках, комментариев (строка в круглых скобках), атомов (строка ASCII-символов, кроме пробельных, специальных и управляющих) и доменных констант (строка в квадратных скобках). Специальные символы теряют свое «специальное» значение, если им предшествует обратная косая черта. В структурированном теле поля несколько идущих подряд пробельных символов трактуются как один пробел. Комментарии могут быть вложенными, трактуются как один пробел. Регистр букв (символьная или строчная) различается только в текстовых строках. В частности, нет разницы между именем поля «From» и «froM». BS действует только до начала физической строки или строки в кавычках. При прохождении внутри сети CRLF может преобразовываться в CR, при выходе CR преобразуется обратно в CRLF (так что отдельные CR или LF использовать небезопасно, а в RFC 2822 явно запрещено).

Формат даты унаследован с 1970-х годов и выглядит так: Tue, 5 Feb 02 00:59:59 +0300. День недели с запятой и секунды с двоеточием можно опускать. Заметьте 2 цифры, отведенные на номер года в RFC 822 (увеличено до 4 цифр в RFC 1123, RFC 2822). Последнее слово определяет смещение локальной временной зоны относительно UTC в часах и минутах. Иногда используются сокращенные наименования временных зон вместо смещения, но это не рекомендуется (а в RFC 2822 явно запрещается). Для временной зоны UTC должно указываться смещение +0000. Смещение -0000 обозначает отсутствие информации о временной зоне.

Адрес почтового ящика состоит из локальной части (слова через точку, не интерпретируется, строчные и прописные буквы различаются), знака «@» и доменной части. Доменная часть — имена поддоменрв, разделенные точками или явное указание IP-адреса в квадратных скобках. Имя домена может быть полным или сокращенным (сокращенное имя домена вызывает множество неприятных ситуаций). Точка справа отсутствует. Не забывайте, что текст в круглых скобках является комментарием. Если имеется текст в угловых скобках, то именно он является адресом, а предваряющая его фраза является описанием адресата и предназначена для вывода на экран. Может быть указан явный маршрут (source routing), хотя не рекомендуется, а в RFC 2822 явно запрещается: список доменных имен (предваряемых знаком «@») через запятую, завершающийся двоеточием. Иногда в локальную часть адреса встраивают маршруты UUCP и других не TCP/IP сетей. Бытует также обычай встраивать source routing в локальную часть адреса с использованием символов процента в качестве разделителей хостов. Резервируется локальная часть адреса — Postmaster (регистр не важен). В каждом домене должен быть Postmaster, отвечающий за работу почты.

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

Часть синтаксиса описывается в RFC 2822 как «устаревший» (определенный в RFC 822 или исторически сложившийся). Сообщения с устаревшим синтаксисом не должны создаваться, но должны обрабатываться, если уж встретились. Например:

  • отдельно стоящие CR или LF
  • символ NUL
  • точка внутри фразы
  • пустая фраза
  • строка продолжения из одних пробельных символов и комментариев
  • номер года из 2 цифр
  • указание временной зоны по имени вместо смещения
  • явная маршрутизация в адресах (source routing) должна игнорироваться
  • строка в кавычках в локальной части адреса
  • пустые элементы списка адресов
  • пробельные символы перед двоеточием в имени поля
  • фразы в полях In-Reply-To и References

RFC 2822 посылает желающих использовать не-ASCII символы как в заголовках, так и в теле сообщения к MIME.

Date. Время, когда автор сообщения заявил, что оно готово к отправке (MUA может отложить отправку, например, до следующего соединения с интернет).

From. Отправитель сообщения (человек или процесс), указывается адрес почтового ящика или список адресов. Если отсутствует поле Sender, то в поле From обязательно должен быть один адрес. Если поле Sender присутствует в заголовке, то в поле From может быть несколько адресов через запятую (таким образом обозначаются авторы сообщения, реальный отправитель определяется полем Sender).

Sender. Определяет отправителя письма (см. выше описание поля From), указывается адрес почтового ящика. Обязательно, если в поле From указано несколько адресов. Сообщения об ошибках доставки почты посылаются ему (но не ответы на сообщения!).

Reply-To. Может содержать список адресов или групп адресов для ответа через запятую. Если присутствует, то ответ на сообщение не должен посылаться по адресу, указанному в поле From или Sender.

Должна быть учтена возможность совпадения адресов в полях From, Sender или Reply-To. Стандарт явным образом запрещает использовать чужие адреса в этих полях.

To. Адреса основных получателей сообщения или группы адресов через запятую.

Cc. Адреса дополнительных получателей сообщения или группы адресов через запятую. Используется, если в тексте письма к ним не обращаются напрямую.

Bcc. Адреса третьей группы получателей или группы адресов через запятую. Список может быть пустым. Данные адреса не включаются в копии сообщений, отправляемых первым двум группам. Либо поле Bcc изымается из письма вовсе, либо удаляется тело поля, либо оно изымается из тех копий письма, которые отсылаются первым двум группам, при этом каждый получатель из списка Bcc получает свою копию, из которой удалены все остальные адреса. С конвертом надо тоже обращаться аккуратно.

Должен быть хотя бы один адрес в поле To, Cc или поле Bcc, даже пустое.

Message-ID. Уникальный идентификатор этой версии этого сообщения (добавление полей Received и Resent- и тому подобные преобразования не порождают новой версии). Уникальность гарантируется генерирующим хостом. Заключается в угловые скобки и состоит из части, однозначно идентифицирующей хост (доменное имя или явный адрес в квадратных скобках), и части, однозначно идентифицирующей сообщение внутри хоста, разделенных знаком «@». Необязательное поле, но крайне желательное.

In-Reply-To. Уникальный идентификатор сообщения (сообщений) через пробел или фраза (фразы), на которые дается ответ в данном сообщении. Фразы удалены из RFC 2822.

References. Уникальный идентификатор сообщения (сообщений) через пробел или фраза (фразы), на которые ссылается данное сообщение (содержимое полей Message-ID, In-Reply-To и References исходного сообшения). Фразы удалены из RFC 2822.

Некоторые почтовые системы позволяют пользователям перепосылать письмо без изменения полей заголовка. Надо отличать перепосылку (resending) от пересылки (forwarding). В этом случае добавляются поля «Resent-. «, смысл которых совпадает со смыслом полей без слова Resent, но они относятся к субъекту, переславшему письмо: Resent-Reply-To (запрещен в RFC 2822), Resent-From, Resent-Sender, Resent-Date, Resent-To, Resent-cc, Resent-bcc, Resent-Message-ID. Вся группа полей должна быть добавлена в начало сообщения вместе, так чтобы самые «свежие» поля Resent- стояли в начале заголовка, остальные заголовки меняться не должны. Если данная группа полей используется, то поля Resent-From и Resent-Date должны быть.

Keywords. Ключевые слова или фразы в кавычках, разделенные запятыми.

Subject. Тема сообщения. Неструктурированный текст. Ответное сообщение обычно имеет ту же тему, перед которой стоит строка «Re: «.

Comments. Неструктурированный текст.

Return-Path. RFC 2822 оставляет определение синтаксиса и семантики данного поля за стандартом SMTP (RFC 2821). Согласно RFC 822 поле добавляется последней транспортной системой (MTA), которая отправляет сообщение получателю, и содержит информацию достаточную этому MTA для определения обратного маршрута (совершенно необходимо для протоколов типа UUCP). Необязательное поле, но если есть, то также должно быть хотя бы одно поле Received. Представляет собой адрес почтового ящика в угловых скобках, перед которым может быть записана цепочка имен хостов, предваряемых знаком «@» и двоеточие. Адрес может быть пустым (<>), используется для предотвращения зацикливания сообщений об ошибках.

Received. Добавляется каждым MTA по пути следования сообщения. RFC 2822 оставляет определение синтаксиса и семантики данного поля за стандартом SMTP (RFC 2821). Согласно RFC 822 тело поля содержит следующую информацию (обязательно только with, причем их может быть несколько, и время):

  1. from домен (от какого хоста получено данным MTA, полное каноническое имя; записывается имя, сообщенное отправившим MTA и затем (в скобках) его реальный IP-адрес и имя; при несовпадении прямой и обратной проверки DNS записывается предупреждение)
  2. by домен (на каком хосте работает данный MTA, полное каноническое имя; здесь же обычно записывается название MTA и номер версии)
  3. via атом (физическая сеть: Internet, JANET, хотя встречаются и слова типа HTTP)
  4. with атом (почтовый протокол — SMTP, ESMTP)
  5. id идентификатор-сообщения (внутренний идентификатор принимающего MTA, если он хранит сообщение в очереди)
  6. for адрес (если принимающий MTA преобразует адрес получателя, то здесь сохраняется исходная форма)
  7. ; время-получения (формат такой же, как у поля Date)

Encrypted. Первое слово определяет программу шифрования, второе — индекс в таблице ключей. Удален в RFC 2822.

Content-Type. Введено RFC 1049 для автоматического распознавания типа содержимого тела сообщения.

Encoding. Введено RFC 1505 для автоматического распознавания типа содержимого тела сообщения (см. ниже).

RFC 934 предлагает при включении письма внутрь другого письма с целью его пересылки (письма делятся на оригинальные, ответы — reply, пересылаемые письма — forward, распространяемые письма — distribution) отделять его строками тире. До сих пор используется (Netscape называет это «forward inline» в противовес MIME-стилю «forward as attach»). Предусмотрена неограниченная вложенность.

RFC 1153 определяет формат упаковки нескольких сообщений списка рассылки в одно. Поле Subject содержит имя списка, слово Digest, буква V, за которой следует номер тома, символ диез, за которым следует номер выпуска. Тело сообщения содержит преамбулу (обычно содержит оглавление из полей Subject, включенных сообщений), одно или несколько включенных сообщений и завершающий текст. Включенное сообщение содержит поля заголовка Date, From, To, Cc, Subject, Mesage-ID, Keywords из исходного сообщения (обязательно в этом порядке), пустую строку и тело исходного сообщения. Преамбула отделяется 70-ю знаками тире и пустой строкой. После каждого включенного сообщения ставится пустая строка, строка из 30 тире и еще одна пустая строка. Завершающий текст состоит из 2 строк. Первая содержит слова End of , за которыми следует имя списка, слово Digest, буква V, за которой следует номер тома, символ диез, за которым следует номер выпуска. Вторая строка состоит из звездочек.

Попытка определить формат сообщения, состоящего из нескольких частей, каждая из которых имела собственную кодировку была предпринята в RFC 1154 и RFC 1505. Разбиение тела сообщения на части, для каждой части определяется свой тип кодирования. Размер части задается явным указанием числа строк. Вводит поле Encoding, указывающее для каждой части число строк и тип кодирования (text — простой текст, message — вложенное сообщение, hex — каждый байт представляется двумя шестнадцатеричными цифрами, X.400, uuencode, encrypted, FS — файл, LZJU90 — сжатие и преобразование в текстовый вид, LZW — сжатие в формате compress, PEM — шифрование, PGP — сжатие, шифрование и преобразование в текстовый вид, TAR, PostScript, SHAR, URL). К каждой части последовательно может применяться несколько методов кодирования. Вложенное сообщение может иметь свое поле Encoding. Проверив на массиве из 25000 писем и 20000 статей, нашел один случай использования (uuencode-вложения, сделанные Microsoft Internet E-mail/MAPI), хотя отличительные признаки файлов, встроенных в сообщение, — имя файла и атрибуты в квадратных скобках — ранее встречались довольно часто.

Дальнейшая разработка стандартов тела сообщения пошла в рамках MIME.

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

Перечисление полей заголовка, добавляемых к сообщению шлюзом X.400 -> RFC822 для писем и извещений и представление адресов X.400 вынесено в отдельную статью.

  • RFC 822. STD 11. Revised by David H. Crocker, «STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES», August 13, 1982. Базовый стандарт на формат сообщения. Отменен RFC 2822.
  • RFC 886. M.T. Rose, Proposed standard for message header munging, Dec-15-1983. Предлагается при трансформации сообщения из одного стандарта в другой заносить ошибки в поля Illegal-Field и Illegal-Object.
  • RFC 915. M.A. Elvy, R. Nedved, Network mail path service, Dec-01-1984. Сервис uucp-path (117/ucp) и протокол. Позволяет по почтовому неинтернетовскому адресу (UUCP, BITNET и др.) определить его адрес в формате RFC 822 (адрес шлюза и локальную часть адреса, которая позволит шлюзу переслать письмо адресату).
  • RFC 934. M.T. Rose and E.A. Stefferud, «Proposed Standard for Message Encapsulation,» January 1985.
  • RFC 976. Mark. R. Horton, UUCP Mail Interchange Format Standard, February 1986. Адаптация почты UUCP к формату сообщения RFC 822 и доменным адресам RFC 920, определение формата конверта («From «, «>From «, «From_ «), адресации и маршрутизации почты в смешанном окружении.
  • RFC 1049. M. Sirbu, A CONTENT-TYPE HEADER FIELD FOR INTERNET MESSAGES, March 1988. Неприжившийся предшественник MIME. Ввел поле Content-Type.
  • RFC 1123. R. Braden, Editor, Requirements for Internet Hosts — Application and Support, October 1989. Содержит уточнения к RFC 822.
  • RFC 1137. Kille, S., «Mapping between full RFC 822 and RFC 822 with restricted encoding», October 1989. Преобразование адресов RFC 822 для сетей, не поддерживающих полную кодировку (UUCP). В частности, пробел заменяется на подчеркивание, специальные символы кодируются буквами, обрамленными знаками диез.
  • RFC 1153. F.J. Wancho, Digest message format, Apr-01-1990.
  • RFC 1154. D. Robinson, R. Ullmann, Encoding header field for internet messages, Apr-01-1990. Отменен RFC 1505.
  • RFC 1505. Costanzo, A., Robinson, D. and R. Ullmann, «Encoding Header Field for Internet Messages», August 1993. Отменяет RFC 1154.
  • RFC 2822. Resnick, P., Editor, «Internet Message Format», April 2001. Базовый стандарт на формат сообщения в Интернет. Отменяет RFC 822.
  • Klyne. XML coding of RFC822 messages. 10 September 2001. draft-klyne-message-rfc822-xml-02.txt.
  • ———————————————————
  • RFC 2076. Palme, J., «Common Internet Message Headers», February 1997.
  • Palme, J., «Common Internet Message Header Fields», Internet draft draft-palme-mailext-headers-06, November 2001.

Bog BOS: Формат сообщений интернет (от RFC822 к RFC2822)

RFC — лучший путеводитель по стандартам

Часто в процесе разработки какого либо приложения возникают вопрос о свойствах тех или иных объэктах, какой разделитель использовать для параметров, какая максимальная длина может быть для тех или иных параметров, например максимальная длина для E-Mail адреса — на все эти вопросы можно найти ответ в RFC докумендах.

RFC в переводе с английского означает «Запрос комментариев» (англ. Request for Comments, RFC) «Request for Comments» ещё можно перевести как «заявка на обсуждение» или «тема для обсуждения». В настоящее время первичной публикацией документов RFC занимается IETF под эгидой открытой организации Общество Интернета (англ. Internet Society, ISOC). Правами на RFC обладает именно Общество Интернета.

Максимальная длина E-Mail адреса

Так например если мы хотим выяснить максимально возможную длину для E-Mail адреса, то нам следует обратится к спецификации «Mail Transfer Protocol» воспользовавшись страницей поиска. В результате могут быть RFC стандарты с одинаковым наименованием и разным номером RFC, в таком случае следует дополнительно обращать внимание на значение в графе «Status».

Так например по нашему запросу «Mail Transfer Protocol» мы получили примерно такой результат:

RFC документы могут иметь один из приведённых ниже статусов:

  • Unknown — Неизвестно
  • Standard — Текущий/действующий стандарт
  • Experimental — Експериментальный
  • Historic — Исторический
  • Informational — Информационный
  • Proposed Standard — Предложенный стандарт
  • Draft Standard — Проект стандарта

В нашем случае мы хотим определится с максимальной длиной E-Mail адреса, а поэтому выбираем для прочтения документ «RFC 821» описывающий стандарт «Simple Mail Transfer Protocol» и имеющий соответствующий статус «Standard», доступный по адресу http://datatracker.ietf.org/doc/rfc821/:

Из документа «RFC 821» который описывает стандарт «Simple Mail Transfer Protocol» следует, что для имени E-Mail пользователя и имени E-Mail домена максимальная длина установлена в 64-е символа, а следовательно 64 + @ + 64 = 129 максимально возможная длина E-Mail адреса составляет 129 символов.

Но, если мы просмотрим документ «RFC 2821 Simple Mail Transfer Protocol» предложенный J. Klensin из AT&T Laboratories, который устарел с выходом «RFC 5321 Simple Mail Transfer Protocol«, то обнаружим, что предлагается количество сомволов в имени E-Mail домена расширить до 255-ти символов:

Возможно J. Klensin из AT&T Laboratories и мае рацию и количество сомволов в имени E-Mail домена следовало бы расширить до 255-ти символов для каких то отдельных случаев но, подумайте сами. как вы будете набирать имя почтового домена состоящее из 255-ти символов ?:)

С взглядом в будущее максимальная длина E-Mail адреса будет равна 64 + @ + 255 = 320 символам, я решил остановится на действующем стандарте «RFC 821» 64 + @ + 64 = 129 максимально возможная длина E-Mail адреса 129 символов и с небольшим взглядом в будущее общее число символов для E-Mail адреса увеличил до 255-ти, мало ли что !:))

Ограничение длины URL-адреса

В документе RFC 2616 «Протокол HTTP/1.1» не определены требования к длине URL-адреса но, в Microsoft Internet Explorer максимальная длина URL-адреса ограничена 2083 символами. Кроме того, максимально допустимая длина пути в Internet Explorer составляет 2048 символов. Эти ограничения относятся к URL-адресам как для запросов POST, так и для запросов GET.

При использовании метода GET ограничение составляет 2048 символов за вычетом количества символов в текущем пути. В то же время метод POST не ограничен размером URL-адреса при отправке пар имя/значение. Эти пары пересылаются в заголовке, а не в URL-адресе.

Дополнительная информация

Если нужно определится со свойствами тех или иных объэктов, какой разделитель использовать для параметров, какая максимальная длина может быть для тех или иных параметров, то эту информацию следует черпать из стандартов описаных в RFC документах и не тратить попусту время на постинг подобных вопросов на различных форумах, сайтах, wikipedia-х и т.д. — RFC документы должны стоять на первом месте.

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

Далее небольшой список ссылок на полезные RFC стандарты:

Илон Маск рекомендует:  Тег small
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL
@ Карта сайта News Автора!