Http протокол руководство

HTTP (HyperText Transfer Protocol — протокол передачи гипертекста) — символьно-ориентированный клиент-серверный протокол прикладного уровня без сохранения состояния, используемый сервисом World Wide Web.

Основным объектом манипуляции в HTTP является ресурс, на который указывает URI (Uniform Resource Identifier – уникальный идентификатор ресурса) в запросе клиента. Основными ресурсами являются хранящиеся на сервере файлы, но ими могут быть и другие логические (напр. каталог на сервере) или абстрактные объекты (напр. ISBN). Протокол HTTP позволяет указать способ представления (кодирования) одного и того же ресурса по различным параметрам: mime-типу, языку и т. д. Благодаря этой возможности клиент и веб-сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.

100 Continue (Продолжать)
101 Switching Protocols (Переключение протоколов)
102 Processing (Идёт обработка)

200 OK (Успешно).
201 Created (Создано)
202 Accepted (Принято)
204 No Content (Нет содержимого)
206 Partial Content (Частичное содержимое)

300 Multiple Choices (Множественный выбор)
301 Moved Permanently (Перемещено навсегда)
304 Not Modified (Не изменялось)

401 Unauthorized (Неавторизован)
402 Payment Required (Требуется оплата)
403 Forbidden (Запрещено)
404 Not Found (Не найдено)
405 Method Not Allowed (Метод не поддерживается)
406 Not Acceptable (Не приемлемо)
407 Proxy Authentication Required (Требуется аутентификация прокси)

500 Internal Server Error (Внутренняя ошибка сервера)
502 Bad Gateway (Плохой шлюз)
503 Service Unavailable (Сервис недоступен)
504 Gateway Timeout (Шлюз не отвечает)

Server: Apache/2.2.3 (CentOS)
Last-Modified: Wed, 09 Feb 2011 17:13:15 GMT
Content-Type: text/html; charset=UTF-8
Accept-Ranges: bytes
Date: Thu, 03 Mar 2011 04:04:36 GMT
Content-Length: 2945
Age: 51
X-Cache: HIT from proxy.omgtu
Via: 1.0 proxy.omgtu (squid/3.1.8)
Connection: keep-alive

200 OK

http://www.example.org/

GET http://www.example.org/ HTTP/1.1
Host: www.example.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.2.13) Gecko/20101203 SUSE/3.6.13-0.2.1 Firefox/3.6.13
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru-ru,ru;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Proxy-Connection: keep-alive

HTTP/1.0 302 Moved Temporarily
Date: Thu, 03 Mar 2011 06:48:28 GMT
Location: http://www.iana.org/domains/example/
Server: BigIP
Content-Length: 0
X-Cache: MISS from proxy.omgtu
Via: 1.0 proxy.omgtu (squid/3.1.8)
Connection: keep-alive
----------------------------------------------------------
http://www.iana.org/domains/example/

GET http://www.iana.org/domains/example/ HTTP/1.1
Host: www.iana.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.2.13) Gecko/20101203 SUSE/3.6.13-0.2.1 Firefox/3.6.13
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru-ru,ru;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Proxy-Connection: keep-alive

HTTP/1.0 200 OK
Server: Apache/2.2.3 (CentOS)
Last-Modified: Wed, 09 Feb 2011 17:13:15 GMT
Content-Type: text/html; charset=UTF-8
Accept-Ranges: bytes
Date: Thu, 03 Mar 2011 04:04:36 GMT
Content-Length: 2945
Age: 9858
X-Cache: HIT from proxy.omgtu
Via: 1.0 proxy.omgtu (squid/3.1.8)
Connection: keep-alive

....

Как зарабатывать больше с помощью нейросетей?
Бесплатный вебинар: 15 экспертов, 7 топ-нейросетей. Научитесь использовать ИИ в своей работе и увеличьте доход.
Узнать больше

Время на прочтение
9 мин

Количество просмотров 1.4M

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

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

Аббревиатура HTTP расшифровывается как HyperText Transfer Protocol, «протокол передачи гипертекста». В соответствии со спецификацией OSI, HTTP является протоколом прикладного (верхнего, 7-го) уровня. Актуальная на данный момент версия протокола, HTTP 1.1, описана в спецификации RFC 2616.

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

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

Также HTTP часто используется как протокол передачи информации для других протоколов прикладного уровня, таких как SOAP, XML-RPC и WebDAV. В таком случае говорят, что протокол HTTP используется как «транспорт».

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

Как правило, передача данных по протоколу HTTP осуществляется через TCP/IP-соединения. Серверное программное обеспечение при этом обычно использует TCP-порт 80 (и, если порт не указан явно, то обычно клиентское программное обеспечение по умолчанию использует именно 80-й порт для открываемых HTTP-соединений), хотя может использовать и любой другой.

Как отправить HTTP-запрос?

Самый простой способ разобраться с протоколом HTTP — это попробовать обратиться к какому-нибудь веб-ресурсу вручную. Представьте, что вы браузер, и у вас есть пользователь, который очень хочет прочитать статьи Анатолия Ализара.

Предположим, что он ввёл в адресной строке следующее:

http://alizar.habrahabr.ru/

Соответственно вам, как веб-браузеру, теперь необходимо подключиться к веб-серверу по адресу alizar.habrahabr.ru.

Для этого вы можете воспользоваться любой подходящей утилитой командной строки. Например, telnet:

telnet alizar.habrahabr.ru 80

Сразу уточню, что если вы вдруг передумаете, то нажмите Ctrl + «]», и затем ввод — это позволит вам закрыть HTTP-соединение. Помимо telnet можете попробовать nc (или ncat) — по вкусу.

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

Для того, чтобы сформировать HTTP-запрос, необходимо составить стартовую строку, а также задать по крайней мере один заголовок — это заголовок Host, который является обязательным, и должен присутствовать в каждом запросе. Дело в том, что преобразование доменного имени в IP-адрес осуществляется на стороне клиента, и, соответственно, когда вы открываете TCP-соединение, то удалённый сервер не обладает никакой информацией о том, какой именно адрес использовался для соединения: это мог быть, например, адрес alizar.habrahabr.ru, habrahabr.ru или m.habrahabr.ru — и во всех этих случаях ответ может отличаться. Однако фактически сетевое соединение во всех случаях открывается с узлом 212.24.43.44, и даже если первоначально при открытии соединения был задан не этот IP-адрес, а какое-либо доменное имя, то сервер об этом никак не информируется — и именно поэтому этот адрес необходимо передать в заголовке Host.

Стартовая (начальная) строка запроса для HTTP 1.1 составляется по следующей схеме:

Метод URI HTTP/Версия

Например (такая стартовая строка может указывать на то, что запрашивается главная страница сайта):

GET / HTTP/1.1

Метод (в англоязычной тематической литературе используется слово method, а также иногда слово verb — «глагол») представляет собой последовательность из любых символов, кроме управляющих и разделителей, и определяет операцию, которую нужно осуществить с указанным ресурсом. Спецификация HTTP 1.1 не ограничивает количество разных методов, которые могут быть использованы, однако в целях соответствия общим стандартам и сохранения совместимости с максимально широким спектром программного обеспечения как правило используются лишь некоторые, наиболее стандартные методы, смысл которых однозначно раскрыт в спецификации протокола.

URI (Uniform Resource Identifier, унифицированный идентификатор ресурса) — путь до конкретного ресурса (например, документа), над которым необходимо осуществить операцию (например, в случае использования метода GET подразумевается получение ресурса). Некоторые запросы могут не относиться к какому-либо ресурсу, в этом случае вместо URI в стартовую строку может быть добавлена звёздочка (астериск, символ «*»). Например, это может быть запрос, который относится к самому веб-серверу, а не какому-либо конкретному ресурсу. В этом случае стартовая строка может выглядеть так:

OPTIONS * HTTP/1.1

Версия определяет, в соответствии с какой версией стандарта HTTP составлен запрос. Указывается как два числа, разделённых точкой (например 1.1).

Для того, чтобы обратиться к веб-странице по определённому адресу (в данном случае путь к ресурсу — это «/»), нам следует отправить следующий запрос:

GET / HTTP/1.1
Host: alizar.habrahabr.ru

При этом учитывайте, что для переноса строки следует использовать символ возврата каретки (Carriage Return), за которым следует символ перевода строки (Line Feed). После объявления последнего заголовка последовательность символов для переноса строки добавляется дважды.

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

Если вы хотите отправить запрос в точном соответствии со спецификацией, можете воспользоваться управляющими последовательностями \r и \n:

echo -en "GET / HTTP/1.1\r\nHost: alizar.habrahabr.ru\r\n\r\n" | ncat alizar.habrahabr.ru 80

Как прочитать ответ?

Стартовая строка ответа имеет следующую структуру:

HTTP/Версия Код состояния Пояснение

Версия протокола здесь задаётся так же, как в запросе.

Код состояния (Status Code) — три цифры (первая из которых указывает на класс состояния), которые определяют результат совершения запроса. Например, в случае, если был использован метод GET, и сервер предоставляет ресурс с указанным идентификатором, то такое состояние задаётся с помощью кода 200. Если сервер сообщает о том, что такого ресурса не существует — 404. Если сервер сообщает о том, что не может предоставить доступ к данному ресурсу по причине отсутствия необходимых привилегий у клиента, то используется код 403. Спецификация HTTP 1.1 определяет 40 различных кодов HTTP, а также допускается расширение протокола и использование дополнительных кодов состояний.

Пояснение к коду состояния (Reason Phrase) — текстовое (но не включающее символы CR и LF) пояснение к коду ответа, предназначено для упрощения чтения ответа человеком. Пояснение может не учитываться клиентским программным обеспечением, а также может отличаться от стандартного в некоторых реализациях серверного ПО.

После стартовой строки следуют заголовки, а также тело ответа. Например:

HTTP/1.1 200 OK
Server: nginx/1.2.1
Date: Sat, 08 Mar 2014 22:53:46 GMT
Content-Type: application/octet-stream
Content-Length: 7
Last-Modified: Sat, 08 Mar 2014 22:53:30 GMT
Connection: keep-alive
Accept-Ranges: bytes

Wisdom

Тело ответа следует через два переноса строки после последнего заголовка. Для определения окончания тела ответа используется значение заголовка Content-Length (в данном случае ответ содержит 7 восьмеричных байтов: слово «Wisdom» и символ переноса строки).

Но вот по тому запросу, который мы составили ранее, веб-сервер вернёт ответ не с кодом 200, а с кодом 302. Таким образом он сообщает клиенту о том, что обращаться к данному ресурсу на данный момент нужно по другому адресу.

Смотрите сами:

HTTP/1.1 302 Moved Temporarily
Server: nginx
Date: Sat, 08 Mar 2014 22:29:53 GMT
Content-Type: text/html
Content-Length: 154
Connection: keep-alive
Keep-Alive: timeout=25
Location: http://habrahabr.ru/users/alizar/

<html>
<head><title>302 Found</title></head>
<body bgcolor="white">
<center><h1>302 Found</h1></center>
<hr><center>nginx</center>
</body>
</html>

В заголовке Location передан новый адрес. Теперь URI (идентификатор ресурса) изменился на /users/alizar/, а обращаться нужно на этот раз к серверу по адресу habrahabr.ru (впрочем, в данном случае это тот же самый сервер), и его же указывать в заголовке Host.

То есть:

GET /users/alizar/ HTTP/1.1
Host: habrahabr.ru

В ответ на этот запрос веб-сервер Хабрахабра уже выдаст ответ с кодом 200 и достаточно большой документ в формате HTML.

Если вы уже успели вжиться в роль, то можете теперь прочитать полученный от сервера HTML-код, взять карандаш и блокнот, и нарисовать профайл Ализара — в принципе, именно этим бы на вашем месте браузер сейчас и занялся.

А что с безопасностью?

Сам по себе протокол HTTP не предполагает использование шифрования для передачи информации. Тем не менее, для HTTP есть распространённое расширение, которое реализует упаковку передаваемых данных в криптографический протокол SSL или TLS.

Название этого расширения — HTTPS (HyperText Transfer Protocol Secure). Для HTTPS-соединений обычно используется TCP-порт 443. HTTPS широко используется для защиты информации от перехвата, а также, как правило, обеспечивает защиту от атак вида man-in-the-middle — в том случае, если сертификат проверяется на клиенте, и при этом приватный ключ сертификата не был скомпрометирован, пользователь не подтверждал использование неподписанного сертификата, и на компьютере пользователя не были внедрены сертификаты центра сертификации злоумышленника.

На данный момент HTTPS поддерживается всеми популярными веб-браузерами.

А есть дополнительные возможности?

Протокол HTTP предполагает достаточно большое количество возможностей для расширения. В частности, спецификация HTTP 1.1 предполагает возможность использования заголовка Upgrade для переключения на обмен данными по другому протоколу. Запрос с таким заголовком отправляется клиентом. Если серверу требуется произвести переход на обмен данными по другому протоколу, то он может вернуть клиенту ответ со статусом «426 Upgrade Required», и в этом случае клиент может отправить новый запрос, уже с заголовком Upgrade.

Такая возможность используется, в частности, для организации обмена данными по протоколу WebSocket (протокол, описанный в спецификации RFC 6455, позволяющий обеим сторонам передавать данные в нужный момент, без отправки дополнительных HTTP-запросов): стандартное «рукопожатие» (handshake) сводится к отправке HTTP-запроса с заголовком Upgrade, имеющим значение «websocket», на который сервер возвращает ответ с состоянием «101 Switching Protocols», и далее любая сторона может начать передавать данные уже по протоколу WebSocket.

Что-то ещё, кстати, используют?

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

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

Опубликованный в ноябре 2012 года черновик спецификации протокола HTTP 2.0 (следующая версия протокола HTTP после версии 1.1, окончательная спецификация для которой была опубликована в 1999) базируется на спецификации протокола SPDY.

Многие архитектурные решения, используемые в протоколе SPDY, а также в других предложенных реализациях, которые рабочая группа httpbis рассматривала в ходе подготовки черновика спецификации HTTP 2.0, уже ранее были получены в ходе разработки протокола HTTP-NG, однако работы над протоколом HTTP-NG были прекращены в 1998.

На данный момент поддержка протокола SPDY есть в браузерах Firefox, Chromium/Chrome, Opera, Internet Exporer и Amazon Silk.

И что, всё?

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

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

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

Удачи и плодотворного обучения!

HTTP означает Hypertext Transfer Protocol (* протокол прикладного уровня для «переговоров» о доставке Web-сервером документа Web-браузеру. НТТР служит также для передачи XML-файлов, VoiceXML , WML , потокового видео и аудио. Обычно использует порт 80, а в качестве протокола транспортного уровня — TCP . Основной протокол WWW , определённый в RFC 1945 (НТТР 1.0), 2068 и 2616 (НТТР 1.1), с помощью которого HTML-документы пересылаются по Интернету от узла к узлу. НТТР поддерживает постоянные (передача многих объектов) и непостоянные соединения (передача одного объекта веб-документа за сеанс обмена между клиентом и сервером), а также два метода идентификации пользователей: авторизацию и объекты (файлы) cookie. Здесь и далее прим. пер.). Это протокол уровня приложений без запоминания состояния (* stateless; не предусматривает сохранения информации о сессии пользователя; каждая передача данных рассматривается как новая сессия) для общения распределенных информационных систем; также является основой современной Всемирной паутины. Являясь веб-разработчиками, мы все должны иметь четкое представление об этом протоколе.

Давайте рассмотрим этот мощный протокол через призму веб-разработчика. Мы разберем эту тему в двух частях руководства. В первой мы рассмотрим основы и дадим общее представление о заголовках запроса и ответа. В последующей части мы рассмотрим специальные вопросы технологии HTTP, а именно: кэширование, реализацию соединения и аутентификацию (* в системе компьютерной безопасности – процесс, позволяющий установить, что пользователь или компьютер (сервер), пытающийся получить интерактивный доступ к определенной категории информации, компьютерной системе, вычислительной сети или электронной почте, действительно тот, за кого себя выдает).

Хотя я упомяну некоторые детали насчет заголовков, за исчерпывающим описанием вам лучше будет обратиться к RFC (RFC 2616). Я буду ссылаться на определенные части документа RFC на протяжении статьи.

Основы HTTP

HTTP позволяет общаться системам с различной архитектурой и конфигурацией сети (* включает в себя конкретный состав оборудования ЛВС, схему его соединения и сетевое ПО).

Это возможно благодаря тому, что этот протокол предъявляет самые общие требования к системам и не сохраняет состояние между обменами различными сообщениями. 

По этой причине HTTP считается протоколом без запоминания состояния. Для транспортировки сообщений обычно служит протокол TCP (* Transmission Control Protocol; протокол управления передачей, протокол TCP широко используемый в Internet протокол транспортного уровня из набора TCP/IP. Гарантирует доставку передаваемых пакетов данных в нужной последовательности, но трафик при этом может быть весьма неравномерен, так как пакеты испытывают всевозможные задержки), однако может использоваться любой другой подходящий механизм для транспортировки сообщений (* например, QUIC (Quick UDP Internet Connections) –  экспериментальный интернет-протокол, разработанный Google в конце 2012 года). Портом по умолчанию для HTTP является порт 80, но могут использоваться и другие порты.

Также можно добавлять и отправлять специализированные (* связанные с (конкретным)  применением, в отличие от стандартизованных в RFC заголовков) собственные заголовки к серверу (* и от сервера).

Обмен сообщениями между клиентом и сервером идет по схеме «запрос-ответ». Клиент начинает общение, отправляя сообщение запроса HTTP, в ответ на которое сервер отсылает сообщение ответа HTTP. Мы рассмотрим эту основополагающую пару в следующем разделе.

Текущая версия протокола – HTTP/1.1, в которой добавлены дополнительные возможности по сравнению с предыдущей – HTTP/1.0. Среди них, на мой взгляд, наиболее важными являются:   долговременные соединения (* persistent connections; передача в одном TCP-соединении нескольких объектов, причем время существования соединения определяется при конфигурировании веб-службы), кодирование передачи данных типа «chunked» (* по частям) (* chunked transfer-coding; механизм передачи данных в протоколе передачи гипертекста (HTTP), позволяющий надежно доставлять данные от сервера клиенту (чаще всего клиентскому web-браузеру) без необходимости заранее знать точный размер всего тела HTTP-сообщения. Это достигается разбиением сообщения на небольшие части (chunks), а затем передачей каждой части с указанием только её размера (в шестнадцатеричном виде). Окончание передачи сообщения определяется наличием последней части с нулевой длиной. Такой механизм позволяет передать динамически сформированные объекты, для которых нельзя заранее определить размер. Он стал доступен только начиная с HTTP версии 1.1 (HTTP/1.1). Без механизма сhunked transfer encoding с каждым HTTP-пакетом необходимо указывать заголовок Content-Length, чтобы клиент мог найти конец передаваемого сообщения) и тонко гранулированные (* метафорическое определение (обозначение) процесса или системы для работы с небольшими объектами, например, отдельными битами и байтами, а не с относительно большими объектами, например файлами или записями) заголовки, при помощи которых задаются директивы для механизма кэширования. Мы коротко рассмотрим эти возможности в этой части; детальное рассмотрение будет во второй.

URL-адреса

В основе коммуникации во Всемирной паутине лежат сообщения запросов, которые пересылаются при помощи URL-адресов (* Uniform Resource Locator — унифицированный указатель [местонахождения информационного] ресурса). Уверен, что вы уже знакомы с ними, однако для полноты картины мы их кратко рассмотрим. По своей структуре URL-адреса просты; в ней выделяют следующие компоненты:

Обычно используется протокол HTTP, однако им также  может быть и HTTPS (* HTTP Secure; протокол защищенной передачи гипертекстов. Расширение протокола НТТР; совместим с НТТР, но использует порт 443 протокола TCP) для обеспечения связи по защищенному каналу. Портом по умолчанию является 80, однако его можно явно задать, как показано выше. Путь к объекту – это локальный путь к ресурсу на сервере.

Методы

Также в их распоряжении имеются прокси для отладки веб-приложений, например, Fiddler (* работает с трафиком между вашим компьютером и удаленным сервером и позволяет просматривать и менять его) (для Windows) и Charles Proxy (для OSX).

URL-ссылки идентифицируют определенный сервер, с которым мы хотим наладить обмен сообщениями, однако действие, которое должно быть выполнено на сервере,   указывается при помощи методов HTTP. Естественно, что клиент хотел бы выполнить некоторые действия (* методы) на сервере. В HTTP стандартизированы несколько, благодаря которым можно реализовать самые необходимые возможности; эти методы универсальны для всех видов приложений.

Эти методы запроса перечислены ниже:

• GET: для получения существующего ресурса.  В URL-адресе содержится вся необходимая информация для определения местонахождения и возвращения ресурса сервером.
• POST: для создания нового ресурса. Запросы по методу POST обычно содержат данные для создания нового ресурса.
• PUT: для обновления существующего ресурса. В содержимом могут находиться обновленные данные для ресурса.
• DELETE: для удаления существующего ресурса.

Выше перечисленные методы наиболее распространены, и большинство инструментов и фреймворков предоставляют функции для работы с этими методами. Иногда PUT и DELETE рассматриваются как специализированные версии метода POST и могут быть оформлены в виде запросов по методу POST с данными, определяющими точное действие: создать, обновить, удалить.

Также HTTP поддерживает некоторые реже используемые методы:

• HEAD: подобен GET, однако не передается тело сообщения. Он используется для получения заголовков определенного ресурса с сервера, обычно чтобы проверить при помощи временной отметки, не изменился ли ресурс.
• TRACE: используется для получения от сервера информации о «прыжках» (* ближайший маршрутизатор, маршрутизатор, находящийся на расстоянии одного прыжка), через которые прошел запрос. Каждый промежуточный прокси-сервер  (* программа кэширования ответов на посылаемые в Internet или в WWW запросы клиентских частей приложений, работающая на прикладном уровне. Копии полученных Web-страниц, файлов и т. д. хранятся какое-то время на сервере, и при получении последующих аналогичных запросов proxy-сервер сам высылает имеющиеся копии, что позволяет сократить время отклика и объем сетевого трафика. Кроме того, proxy-сервер может фильтровать запросы, закрывая доступ к сайтам определенного типа, обеспечивая таким образом информационную безопасность и возможности административного контроля; средства, защищающие локальную сеть от несанкционированного доступа через интернет; программный агент, действующий от имени пользователя) или шлюз (* сетевое устройство или компьютер, осуществляющие связь между двумя различными, использующими разные коммуникационные протоколы (communications protocol), компьютерными сетями или мэйнфреймом и сетью, соответственно могут выполнять преобразование одного набора протоколов в другой) при этом будут заносить свой IP-адрес (* используется для идентификации узла в сети и для определения информации маршрутизации; состоит из идентификатора сети (network ID) и идентификатора хоста (host ID), присвоенного сетевым администратором) или имя DNS (* механизм, используемый в сети и устанавливающий соответствие между числовыми IP-адресами и текстовыми именами) в поле Via заголовка. Его можно использовать с диагностическими целями.
• OPTIONS: для получения поддерживаемых сервером возможностей. На стороне клиента его можно использовать для изменения запроса в зависимости от возможностей, поддерживаемых сервером.

Коды состояния (* значение, возвращаемой процедурой или функцией, показывающее состояние устройства или процесса)

Имея URL-адреса и методы, клиент может инициировать запросы к серверу. В ответ сервер присылает ответы с кодами состояния и содержимым сообщений. Код состояния – важный компонент сообщения; он указывает клиенту, как интерпретировать ответ сервера. В спецификации (* документ, который в идеале содержит полное, точное, детальное описание функций и/или параметров (например, продукта, программы, стандарта и т. п.), а также, возможно, процедур, позволяющих определить, соответствует ли продукт данной спецификации) HTTP устанавливаются определенные диапазоны чисел для конкретных типов ответов:

1xx: Информация о процессе передачи

Всем клиентам HTTP/1.1 необходимо, чтобы в сообщении был заголовок Transfer-Encoding.

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

2xx: Информация об успешном принятии и обработке запроса клиента

Коды этого класса сообщают клиенту, что его запрос успешно обработан. Наиболее часто встречается код (* и соответствующая поясняющая фраза) 200 OK. На запросы по методу GET сервер отсылает в ответ запрашиваемые данные в теле сообщения. Ниже перечислены некоторые более редко используемые коды (* и соответствующие фразы): 

• 202 Accepted (* Принято): запрос был принят на обработку (* но она не завершена), но в ответе может не быть запрашиваемых данных. Этот вариант полезен для асинхронной обработки на стороне сервера. Сервер может решить отослать информацию для мониторинга (* непрерывный во времени или периодический процесс сканирования состояния каких-либо ресурсов (например, информационных) с целью сбора данных, контроля, управления и/или содержательного анализа).
• 204 No Content (* Нет содержимого): тело сообщения не передается.
• 205 Reset Content (* Сбросить содержимое): клиент должен сбросить (* вернуть исходные значения) введенные пользователем данные (*  тела сообщения сервер при этом не передает и документ обновлять не обязательно).
• 206 Partial Content (* Частичное содержимое): указывает, что в ответе содержится только часть ресурса. Клиент может присылать дополнительные заголовки, при помощи которых указывается точный диапазон запрашиваемого ресурса и информация о сроке действия контента.

3xx: Перенаправление

404 сообщает, что запрашиваемый ресурс не существует на сервере.

Этот код указывает клиенту, что необходимо будет выполнить дополнительное действие. Самый распространенный вариант – выполнение запроса по другому URL-адресу (* указанному в дополнительном заголовке Location) для получения запрашиваемого ресурса.

• 301 Moved Permanently (*  Постоянно перемещен): запрошенный объект был окончательно перенесен на новый URL.
• 303 See Other (* Смотреть другой): запрошенный объект временно перенесен на новый URL. Временный URL указывается в заголовке Location ответа.
• 304 Not Modified (* Не модифицирован): сервер обнаружил, что ресурс не был изменен и клиенту следует использовать копию из кэша. Это реализуется за счет того, что клиент отсылает определенное значение (хэш-значение содержимого) в заголовке ETag (Entity Tag). Сервер сравнивает это значение со своим собственным токеном (* средство идентификации) для запрашиваемого ресурса на наличие изменений.

4xx: Информация об ошибках со стороны клиента

Эти коды используются, когда сервер считает, что клиент допустил ошибку: будь то ошибочный запрос или же запрос недоступного для клиента ресурса. Наиболее популярное сообщение в данном случае — 404 Not Found (*  Не найден), значение которого, думаю, все знают. 404 сообщает, что запрашиваемый ресурс не существует на сервере. Некоторые остальные коды (* и соответствующие фразы) этого класса перечислены ниже:

• 400 Bad Request (Испорченный Запрос): в запросе обнаружена ошибка.
• 401 Unauthorized (*  Несанкционированный доступ): для осуществления запроса необходима аутентификация. Клиент может повторно выполнить запрос, добавив  заголовок Authorization. Если клиент уже использовал этот заголовок, то это значит, что были указаны ошибочные для успешной аутентификации данные.
• 403 Forbidden (* Запрещено): сервер отказал клиенту в доступе к указанному ресурсу. 
• 405 Method Not Allowed (* Метод не допустим): в строке запроса использовался недопустимый метод HTTP или же сервер не поддерживает этот метод.
• 409 Conflict (* Конфликт): сервер не смог выполнить зарос, поскольку клиент попытался изменить ресурс, временная отметка которого не совпадает с таковой клиента. В большинстве случаев конфликтная ситуация возникает при совместном редактировании ресурса с помощью запросов по методу PUT.

5xx: Информация об ошибках со стороны сервера

Этот тип кодов используется для сообщения о неуспешном выполнении операции по вине сервера. Наиболее часто встречающийся код об ошибке (* и соответствующая поясняющая фраза) – 500 Internal Server Error (* Внутренняя ошибка сервера; любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса). Некоторые остальные коды (* и соответствующие поясняющие фразы) этого класса включают:

• 501 Not Implemented (* Не реализовано): сервер на данный момент не поддерживает возможностей, необходимых для обработки запроса.
• 503 Service Unavailable (* Сервис недоступен): сервер не имеет возможности обрабатывать запросы по техническим причинам или перегружен. Обычно сервер даже не будет отвечать, и запрос превысит лимит времени ожидания от сервера (* timeout; истечение времени ожидания события (обычно задается для операций с периферийными устройствами), по которому возникает и обрабатывается, например, ошибочная ситуация (timeout error)).

Формат HTTP-сообщений

На данный момент мы выяснили, что URL-адреса, методы и коды состояния – это фундаментальные компоненты пары HTTP запрос/ответ.

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

1

message = <start-line>

2

          *(<message-header>)

3

          CRLF

4

          [<message-body>]

5

6

<start-line> = Request-Line | Status-Line 

7

<message-header> = Field-Name ':' Field-Value

Размещение пустой строки между заголовками и телом сообщения является обязательным. В сообщении может содержаться один или несколько заголовков, среди которых условно (* согласно контексту) можно выделить:

• общие заголовки (general headers; применимы для сообщений и запроса, и ответа).
• заголовки запроса.
• заголовки ответа.
• заголовки тела объекта (entity headers).

В теле сообщения могут содержаться все данные сообщения или оно может быть разбито на части, если используется кодирование передачи типа «chunked» (Transfer-Encoding: chunked). Всем клиентам HTTP/1.1 необходимо, чтобы в сообщении был заголовок Transfer-Encoding.

Общие заголовки

Имеется несколько заголовков (общие заголовки), которые используются и в сообщениях запроса, и в сообщениях ответа:

1

2

general-header = Cache-Control            

3

               | Connection        

4

               | Date              

5

               | Pragma            

6

               | Trailer           

7

               | Transfer-Encoding 

8

               | Upgrade           

9

               | Via               

10

               | Warning

Мы уже знакомы с некоторыми из этих заголовков (Via и  Transfer-Encoding). Мы рассмотрим Cache-Control и Connection во второй части.

Код состояния – важный компонент сообщения; он указывает клиенту, как интерпретировать ответ сервера.

• Заголовок Via используется в сообщениях, передаваемых по методу TRACE, и обновляется всеми промежуточными прокси и шлюзами.
• Заголовок Pragma считается специализированным заголовком и может быть использован для включения в сообщение связанных с конкретной реализацией приложения заголовков. Наиболее часто используется директива Pragma: no-cache, которая является эквивалентом Cache-Control: no-cache версии HTTP/1.1. Этот заголовок будет рассмотрен во второй части руководства.
• Заголовок Date используется для добавления времени создания сообщений запроса/ответа.
• Upgrade используется для переключения протоколов и позволяет осуществить плавный переход на использование нового протокола.
• Transfer-Encoding обычно используется для разбиения ответа на меньшие части при помощи директивы Transfer-Encoding: chunked. Этот заголовок впервые появился в версии HTTP/1.1; позволяет реализовать потоковую передачу данных  ответа клиенту (* перемещение данных по частям, малыми порциями) (в отличие от пересылки копии данных целиком).

Заголовки для тела сообщения

В сообщениях запроса и ответа также могут использоваться заголовки для тела объекта, чтобы передать мета-информацию о содержимом сообщения (тело сообщения/объекта).  Этот тип заголовков включает:

1

entity-header  = Allow                    

2

               | Content-Encoding  

3

               | Content-Language  

4

               | Content-Length    

5

               | Content-Location  

6

               | Content-MD5       

7

               | Content-Range     

8

               | Content-Type      

9

               | Expires           

10

               | Last-Modified

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

Благодаря заголовку Expires указывается срок, по истечении которого тело сообщения считается  устаревшим. Интересно то, что при указании значения «never expires» этот срок равен одному году. При помощи заголовка Last-Modified указывается время последней модификации файла.

Также можно добавлять и отправлять специализированные собственные заголовки к серверу (* и от сервера); согласно протоколу HTTP они будут  рассматриваться как заголовки объекта.

Эта возможность – механизм расширения полей заголовка (* позволяет вводить дополнительные поля заголовка объекта (entity-header fields), не изменяя протокол, но эти поля могут быть и не распознаны получателем. Получатель должен игнорировать нераспознанные поля заголовка, а прокси-сервер должен просто пересылать их без изменений), и в некоторых реализациях приложений для коммуникации могут использоваться именно эти специальные заголовки. Хотя HTTP поддерживает специализированные заголовки, в первую очередь его интересуют заголовки ответа и запроса, которые мы и будем рассматривать далее.

Формат сообщений запроса

Общая структура сообщения запроса такая же, как и выше, однако строка запроса выглядит следующим образом:

1

Request-Line = Method SP URI SP HTTP-Version CRLF

2

Method = "OPTIONS"

3

       | "HEAD"  

4

       | "GET"  

5

       | "POST"  

6

       | "PUT"  

7

       | "DELETE"  

8

       | "TRACE"

SP – пространственный разделитель между лексемами. На месте HTTP-Version указывается «HTTP/1.1«, и затем идет переход на новую строку. Таким образом, типичное сообщение запроса может выглядеть следующим образом: 

1

GET /articles/http-basics HTTP/1.1

2

Host: www.articles.com

3

Connection: keep-alive

4

Cache-Control: no-cache

5

Pragma: no-cache

6

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Обратите внимание на строку запроса, за которой идет серия заголовков запроса. Заголовок Host является обязательным для клиентов, работающих по HTTP/1.1. Запросы, выполняемые по методу GET, не имеют тела объекта, а запросы, выполняемые по методу POST, могут содержать данные в теле для создания ресурса.

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

1

2

request-header = Accept                   

3

               | Accept-Charset    

4

               | Accept-Encoding   

5

               | Accept-Language   

6

               | Authorization     

7

               | Expect            

8

               | From              

9

               | Host              

10

               | If-Match          

11

               | If-Modified-Since 

12

               | If-None-Match     

13

               | If-Range          

14

               | If-Unmodified-Since

15

               | Max-Forwards       

16

               | Proxy-Authorization

17

               | Range              

18

               | Referer            

19

               | TE                 

20

               | User-Agent

В заголовках с префиксом Accept указываются допустимые для приема клиентом формы информации, язык и набор символов. В From, Host, Referer и User-Agent указываются детали о клиенте, отправившем запрос. Заголовки с префиксом If- используются для придания запросу гибкости, и сервер присылает ответ только тогда, когда заданное условие выполняется. В ином случае присылается ответ 304 Not Modified. Условие может быть задано на основе временной метки или ETag.

Формат сообщений ответа

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

1

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

• На месте HTTP-Version указывается HTTP/1.1.
• Status-Code – один из ранее рассматриваемых кодов состояния.
• Reason-Phrase – понятная человеку версия (* поясняющая фраза) кода состояния.

Типичная стартовая строка ответа об успешном выполнении запроса может выглядеть следующим образом:

Число заголовков ответа также довольно ограничено; полный набор представлен ниже:

1

 response-header = Accept-Ranges

2

                 | Age

3

                 | ETag              

4

                 | Location          

5

                 | Proxy-Authenticate

6

                 | Retry-After       

7

                 | Server            

8

                 | Vary              

9

                 | WWW-Authenticate

• В Age указывается время в секундах, когда сообщение было сгенерировано на сервере.
• Значение ETag – хэш-значение объекта, полученное с помощью алгоритма шифрования MD5 (* Message Digest 5); используется для проверки наличия изменений ресурса.
• Location используется для инструктирования клиента о перенаправлении и содержит новый URL-адрес.
• В Server указывается сервер, который прислал сообщение.

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

Инструменты для просмотра сетевого трафика по HTTP (* поток данных в передающей среде;  состоит из передаваемых данных и служебной информации, необходимой для организации их прохождения)

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

Без сомнений, фаворитом среди веб-разработчиков  является инспектор Chrome/Webkit.

Также в их распоряжении имеются прокси для отладки веб-приложений, например, Fiddler (* работает с трафиком между вашим компьютером и удаленным сервером и позволяет просматривать и менять его) для Windows и Charles Proxy для OSX. Мой коллега, Rey Bango, написал замечательную статью на эту тему. Мой коллега, Rey Bango, написал замечательную статью на эту тему.

Из набора программ с интерфейсом командной строки для мониторинга трафика HTTP у нас имеются такие утилиты, как curl, tcpdump и tshark.

Использование HTTP во фреймворках и библиотеках

Теперь, когда мы рассмотрели сообщения запроса/ответа, пришло время ознакомиться с тем, какой API библиотеки и фремворки предоставляют для работы с ними. Мы рассмотрим примеры из ExpressJS (для Node), Ruby on Rails (* фреймворк, написанный на языке программирования Ruby, реализует архитектурный шаблон Model-View-Controller для веб-приложений, а также обеспечивает их интеграцию с веб-сервером и сервером баз данных) и jQuery Ajax. Мы рассмотрим примеры из ExpressJS (для Node), Ruby on Rails (* фреймворк, написанный на языке программирования Ruby, реализует архитектурный шаблон Model-View-Controller для веб-приложений, а также обеспечивает их интеграцию с веб-сервером и сервером баз данных) и jQuery Ajax.

ExpressJS

Если вы создаете веб-серверы на Node.js, то наверняка уже знакомы с ExpressJS. Прототипом ExpressJS послужил веб-фреймворк для Ruby – Sinatra. Не удивительно, что API ExpressJS подобен его API.

Поскольку мы имеем дело с фреймворком для серверной стороны, то при работе с сообщениями HTTP необходимо выполнить два действия:

• Прочитать фрагменты URL и заголовки запроса.
• Добавить заголовки ответа и тело.

Понимание HTTP очень важно для реализации простого добротного RESTful (* веб-службы, построенные с учётом REST (передача состояния представления; архитектурный стиль взаимодействия компонентов распределенного приложения в сети)) — интерфейса между двумя оконечными узлами локальной сети.

ExpressJS как раз предоставляет для этого простой API. Мы не будем рассматривать детали API. Вместо этого я предоставлю вам ссылки на детальную документацию по ExpressJS. Здесь будут перечислены наиболее популярные. Некоторые примеры методов API, связанных с обработкой запросов, приведены ниже:

• req.body: для получения тела запроса.
• req.query: для получения фрагмента запроса URL.
• req.originalUrl
• req.host: для прочтения поля Host заголовка.
• req.accepts: для получения допустимых на стороне клиента типов MIME (* многоцелевые расширения почты (почтовой службы) в Интернете; набор стандартов для передачи мультимедийной информации посредством электронной почты). 
• req.get или req.header: для прочтения любого поля заголовка, переданного в виде аргумента.

Для формирования ответа клиенту ExpressJS предоставляет следующий API:

• res.status: для явного указания кода состояния.
• res.set: для указания определенного заголовка.
• res.send: для отправления HTML, JSON или последовательности октетов.
• res.sendFile: для передачи файла клиенту.
• res.render: для выполнения шаблона представления  Express.
• res.redirect: для перенаправления на другой маршрут. Express автоматически добавляет код по умолчанию о перенаправлении 302.

Ruby on Rails

Формат сообщений запроса и ответа сходен (различия есть в стартовой строке и заголовках сообщений).

В Rails модули ActionController и ActionDispatch предоставляют API для обработки сообщений запроса и ответа.

ActionController предоставляет высокоуровневый API для получения URL запроса, обработки результата и перенаправления на другой маршрут. Конечная точка (маршрут) используется для выполнения указанного в нем метода (действия) (* например, если пользователь переходит по /clients/new в вашем приложении для добавления нового клиента, Rails создаст образец ClientsController и вызовет его метод new). Большинство необходимой контекстной (* связанной с конкретным запросом) информации внутри метода становится доступной благодаря объектам request, response и params.

• params: предоставляет доступ к параметрам URL и данным, переданным по методу POST.
• request: содержит информацию о клиенте, заголовках и URL.
• response: используется для установления значений заголовков и кодов состояния.
• render: для исполнения шаблонов.
• redirect_to: используется для перенаправления к другому методу или на другой URL.

ActionDispatch предоставляет тонко гранулированный доступ к сообщениям запроса/ответа при помощи классов  ActionDispatch::Request и ActionDispatch::Response. Этот модуль предоставляет набор методов для проверки типа запроса (get?(), post?(), head?(), local?()). Заголовки запроса можно напрямую получить при помощи метода request.headers() .

Для работы с ответом модуль предоставляет методы  cookies(), location=() и status=(). Если вы хотите поэкспериментировать, то можете также задать тело ответа вручную при помощи body=().

AJAX (* Asynchronous JavaScript And XML – асинхронный JavaScript + XML) jQuery

Поскольку jQuery – прежде всего, библиотека для клиентской части приложения, то API AJAX предоставляет возможности, противоположные тем, что реализуются на стороне сервера. Другими словами, благодаря ей вы можете прочитывать и изменять сообщения запроса. jQuery предоставляет доступ к простому API при помощи jQuery.ajax(settings):

Передавая объект settings , в состав которого входит функция обратного вызова beforeSend, мы можем изменять заголовки запроса. В нее передается объект jqXHR (jQuery XMLHttpRequest), у которого имеется метод (setRequestHeader()) для указания значений заголовков.

1

2

$.ajax({

3

    url: 'http://www.articles.com/latest',

4

    type: 'GET',

5

    beforeSend: function (jqXHR) {

6

      jqXHR.setRequestHeader('Accepts-Language', 'en-US,en');

7

    }

8

  });

• Объект jqXHR также может быть использован для прочтения заголовков ответа при помощи метода jqXHR.getResponseHeader().
• Если вы хотите выполнять определенные действия по приходу различных кодов состояния, то вы можете указать функцию обратного вызова в объекте statusCode.

1

2

$.ajax({

3

  statusCode: {

4

    404: function() {

5

      alert("page not found");

6

    }

7

  }

8

});

Резюме

Давайте теперь подведем итог нашему краткому разбору протокола HTTP.

Мы ознакомились со структурой URL-адреса, методами и кодами состояния – тремя китами коммуникации при помощи HTTP.

Формат сообщений запроса и ответа сходен (различия есть в стартовой строке и заголовках сообщений). И, наконец, мы рассмотрели, как вы можете работать с заголовками запроса и ответа во фреймворках и библиотеках.

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

Во второй части мы разберем реализацию соединений, аутентификацию и кэширование! Тогда и увидимся.

Ссылки

• Спецификация HTTP
• Полное руководство по HTTP