Протоколы (HTTP, FTP, SMTP)

Технологии работы с открытыми данными

Об уроке

4.1 Протоколы (HTTP, FTP, SMTP и т. д.) для Curl запросов

Общие сведения cURL

cURL (англ. client URL или Curl URL Request Library [23])— (распространяемая по лицензии MIT) [24] кроссплатформенная служебная программа командной строки, позволяющая взаимодействовать с множеством различных серверов по множеству различных протоколов с синтаксисом URL.

Оригинальным автором является Даниэль Стенберг. Общее число разработчиков — 6.

С приходом обновления Redstone 4 «April 2018 Update» (версия 1803) для Windows 10 программа cURL была включена в состав этой операционной системы [25]. Не путать с языком программирования Curl.

Возможности

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

Программа поддерживает протоколы: FTP, FTPS, HTTP, HTTPS, TFTP, SCP, SFTP, Telnet, DICT, LDAP, а также POP3, IMAP и SMTP. Также cURL поддерживает сертификаты HTTPS, методы HTTP POST, HTTP PUT, загрузку на FTP, загрузку через формы HTTP.

Поддерживаемые методы аутентификации: базовая, дайджест, NTLM и Negotiate для HTTP, а также Kerberos для FTP.

Возможно возобновление передачи файла с места обрыва (при поддержке протоколом), туннелирование через HTTP-прокси, поддержка HTTP-Cookie.

cURL — это не офлайн-браузер типа HTTrack и он не может целиком загрузить содержимое сайта [26]. Первый выпуск: 1996 г [27].

Автор: Даниэль Стенберг — шведский разработчик программного обеспечения, лауреат премии Polhem 2017 за его работу над cURL [28].

Библиотека Libcurl

Libcurl — это библиотека API для передачи, которую разработчики могут встроить в свои программы; cURL действует как автономная обёртка для библиотеки libcurl. libcurl используется, чтобы обеспечить возможность передачи файлов (адресуемых с помощью URL) многочисленным приложениям (как открытым, так и коммерческим).

Для libcurl имеются модули интеграции (bindings, привязки) для работы с более чем 30 языками программирования.

Ссылки

Официальный сайт: https://curl.se/

Руководство: https://curl.se/docs/manpage.html

Документация для libcurl на русском:

https://libcurl.fandom.com/ru/wiki/Libcurlru_%D0%B2%D0%B8%D0%BA%D0%B8

HTTP-методы

Как происходит управление информацией сервиса – это целиком и полностью основывается на протоколе передачи данных [29]. Наиболее рас- пространенный протокол – HTTP. Для HTTP действие над данными за- дается с помощью методов.

Проектирование операций на HTTP-методы становится легче, ко- гда вы знаете характеристики всех методов HTTP. Ниже представлены две характеристики, которые должны быть определены перед использо- ванием HTTP-метода:

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

Не все методы являются безопасными и идемпотентными. В табл. 4.1 представлен список методов, которые используются в REST-приложениях и показаны их свойства.

Таблица 4.1 – HTTP-методы

HTTP-метод	Безопасный	Идемпотентный
GET	Да	Да
POST	Нет	Нет
PUT	Нет	Да
DELETE	Нет	Да
OPTIONS	Да	Да
HEAD	Да	Да

Ниже приведен краткий обзор каждого метода и рекомендации по их использованию:

GET: метод является безопасным и идемпотентным. Обычно ис- пользуется для извлечения информации и не имеет побочных эффектов;
POST: метод не является ни безопасным, ни идемпотентным.

Этот метод наиболее широко используется для создания ресурсов;

PUT: метод является идемпотентным. Вот почему лучше ис- пользовать этот метод вместо POST для обновления ресурсов. Избегайте использования POST для обновления ресурсов;

DELETE: как следует из названия, метод используется для уда- ления ресурсов. Но этот метод не является идемпотентным для всех за- просов;
OPTIONS: метод не используется для каких-либо манипуляций с ресурсами. Но он полезен, когда клиент не знает других методов, под- держиваемых для ресурса, и используя этот метод, клиент может полу- чить различное представление ресурса;
HEAD: этот метод используется для запроса ресурса c сервера. Он очень похож на метод GET, но HEAD должен отправлять запрос и получать ответ только в заголовке. Согласно спецификации HTTP, этот метод не должен использовать тело для запроса и ответа;
HTTP: определяет различные коды ответов для указания клиен- ту различной информации об операциях. Далее представлен список ко- дов ответов HTTP:
200 OK – это ответ на успешные GET, PUT, PATCH или DELETE. Данный код также используется для POST, который не приво- дит к созданию;
201 Created – данный код состояния является ответом на POST, который приводит к созданию;
204 Нет содержимого – это ответ на успешный запрос, который не будет возвращать тело (например, запрос DELETE);
304 Not Modified – используйте этот код состояния, когда заго- ловки HTTP-кеширования находятся в работе;
400 Bad Request – данный код состояния указывает, что запрос искажен, например, если тело не может быть проанализировано;
401 Unauthorized – данный код возвращается, если не указаны или недействительны данные аутентификации. Также полезно активировать всплывающее окно auth, если приложение используется из браузера;
403 Forbidden – данный код возвращается, когда аутентификация прошла успешно, но аутентифицированный пользователь не имеет до- ступа к ресурсу;
404 Not found – данный код возвращается, если запрашивается несуществующий ресурс;
405 Method Not Allowed – данный код возвращается, когда за- прашивается HTTP-метод, который не разрешен для аутентифицирован- ного пользователя;
410 Gone – данный код состояния указывает, что ресурс в этой конечной точке больше не доступен. Полезно в качестве защитного от- вета для старых версий API;
415 Unsupported Media Type – данный код возвращается, если в качестве части запроса был указан неправильный тип содержимого;
429 Too Many Requests – данный код возвращается, когда запрос отклоняется из-за ограничения скорости;
- 500 – внутренняя ошибка сервера.

Протокол передачи гипертекста HTTP

Протокол HTTP (Hypertext Transfer Protocol) является протоколом прикладного уровня и используется, начиная с 1990 г., для передачи информации во всемирной паутине (World-Wide Web) [30]. Первая версия этого протокола, называемая HTTP/0.9, описанная в спецификации RFC (Request For Comments) 2109 , являлась простым протоколом для передачи данных по сети Интернет. В версии HTTP/1.0, описанной в спецификации RFC 1945 , была добавлена возможность передачи данных с использованием формата, аналогичного MIME, т.е. с добавлением метаданных о передаваемой по данному протоколу информации и семантики запросов клиента и ответов сервера. Однако в версии HTTP/1.0 не рассматривались вопросы иерархических прокси-серверов, кэширования, необходимости постоянных соединений и виртуальных хостов, что потребовало введения следующей версии протокола, определенной в спецификации RFC 2068 и дополненной спецификацией RFC 2616.

Согласно спецификациям протокола HTTP, все HTTP-транзакции имеют единый формат; запросы клиента и ответы сервера состоят из трех частей: строки запроса (ответа), заголовка запроса (ответа) и тела документа. Транзакция инициируется клиентом путем установления TCP-соединения с сервером по используемому сервером номеру порта. В сети Интернет за протоколом HTTP зарезервирован 80 порт, хотя использоваться может и любой другой. После установления соединения клиент отправляет серверу строку запроса документа, состоящую из метода запроса, адреса запрашиваемого документа (URI – Uniform Resource Identifier) и версии протокола HTTP.

Например, строка запроса

GET /index.html HTTP/1.0

означает, что производится запрос по методу GET документа index.html, расположенного в корневом каталоге сервера, с использованием протокола HTTP версии 1.0. Признаком конца строки в протоколе HTTP считается последовательность CRLF (CR – Carriage Return, возврат каретки; LF – Linefeed, возврат строки; ASCII-коды 13 и 10 соответственно ).

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

USER-AGENT: Mozilla/2.02Gold (WinNT; I)

Accept: image/gif, image/jpeg, image/pjpeg, */*

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

После отправки заголовка запроса клиент может также передать серверу некоторые дополнительные данные. Эти данные главным образом используются CGI-скриптами, обрабатывающими запросы по методу POST, широко применяемому для редактирования размещенной на сайте информации. Ответ сервера на запрошенную клиентом информацию выглядит следующим образом. Первая часть ответа – строка ответа – включает в себя версию протокола HTTP, код ответа сервера и его описание. Код ответа сервера является трехзначным десятичным числом, обозначающим результат обработки запроса сервером, а описание – мнемонической расшифровкой кода, обработка которого на стороне клиента не требуется.

Заголовок ответа

HTTP/1.0 200 OK

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

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

Date: Fri, 20 Mar 1999 08:17:58 GMT

Server: NCSA/1.5.2

Last-modified: Mon, 17 Jun 1996 21:53:08 GMT Content-type: text/html

Content-length: 2482

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

Как и при запросе клиента, признаком окончания заголовка ответа сервера является пустая строка.

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

В протоколе HTTP версии 0.9 соединение закрывается сразу же после передачи данных. В версии 1.0 по умолчанию после передачи данных сервер закрывает соединение (завершая тем самым HTTP-транзакцию), но позволяет сохранить его, если в заголовке запроса указана строка

Connection: Кeep-alive

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

Каждая строка запроса клиента начинается с указания метода, по которому производится запрос документа. Метод указывает серверу способ, которым должен быть обработан запрос. Название методов чувствительно к регистру, поэтому методы GET и Get, вообще говоря, различаются.

В таблице 4.2 приведены методы, определенные спецификацией протокола.

HTTP версии 1.1, и их краткие описания. Основными используемыми методами являются GET, HEAD и POST, в то время как остальные имеют меньшую распространенность.

Таблица 4.2 – Методы HTTP-запросов

Метод	Краткое описание
GET	Метод инициирует получение документа, расположенного по указанному в строке запроса адресу. Этот метод является самым распространенным методом для получения данных с сервера. При запросе по методу GET клиент оправляет строку и заголовок запроса, в то время как тело запроса всегда остается пустым, а сервер отвечает строкой ответа, заголовком ответа и помещенными в тело ответа запрошенными данными. Если данные не могут быть переданы, то в теле ответа передается дополнительная информация, содержащая пояснение о причине появления ошибки. Метод GET может быть использован для передачи CGI-скриптам данных пользователя. Данные в этом случае передаются в строке запроса, разделенные амперсандом (&), после адреса запрашиваемого ресурса (CGI-скрипта), отделенные от адреса знаком вопроса. Например, GET /cgi-bin/books.pl?author=yelenev&bookid=1 HTTP/1.0 Однако при передаче серверу данных с использованием метода GET следует учитывать, что имеется ограничение на максимальную длину переданных данных, практически не позволяющее производить передачу достаточно больших блоков данных на сервер (например, загрузку файлов). В случае подобной необходимости лучше использовать метод POST.
HEAD	Метод идентичен методу GET за исключением того, что в теле ответа сервер ничего не отправляет клиенту. Метаданные, содержащиеся в заголовке ответа, полученного по методу HEAD, должны быть идентичны метаданным, полученным с использованием запроса по методу GET. Метод используется, когда клиент хочет получить только данные о документе, но не сам документ, например, при кэшировании запросов полезна информация о времени последнего изменения документа; данные о размере документа позволяют оценить время, необходимое для получения документа и т.п.
POST	Метод используется для отправки клиентом данных на сервер. Данные, передаваемые на сервер, должны находиться в теле запроса. Данные направляются сервером для обработки в специальную программу (например, CGI-скрипт). Результат обработки запроса по методу POST не должен сказываться на ресурсе, расположенном по указанному в строке запроса адресу. Метод POST разработан для обеспечения следующих функций: – комментирования существующих ресурсов; – отправки сообщений на Интернет-форумы, новостные группы, списки рассылки и т.п.; – передачи блоков данных, таких как результаты отправки форм, процессам обработки данных; удаленного внесения изменений в базы данных.
OPTIONS	Запрашивает информации о коммуникационных параметрах сервера. Позволяет клиенту определить параметры и/или требования, связанные с документом или совместимостью сервера, без инициации запроса данного документа или связанных с ним действий.
PUT	Запрашивает размещение документа, отправляемого в теле запроса, по адресу, указанному в строке запроса адресу.
DELETE	Запрашивает удаление документа, находящегося на сервере по указанному в строке запроса адресу. Запросы по этому методу не кэшируются.
TRACE	Метод позволяет клиенту увидеть без изменений информацию, полученную другой стороной. Используется для отладки. Ответы на запросы по методу TRACE не должны кэшироваться.
CONNECT	Метод зарезервирован спецификацией протокола HTTP версии 1.1 для использования прокси-серверами.

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

Таблица 4.3 – Диапазоны кодов ответов сервера

Диапазон	Расшифровка диапазона в спецификации протокола	Описание
100÷199	Informational	Информационный
200÷299	Successful	Запрос клиента успешно принят и обработан
300÷399	Redirection	Запрос клиента переадресован
400÷499	Client Error	Ошибка клиента
500÷599	Server Error	Ошибка сервера

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

Таблица 4.4 – Информационные коды ответа сервера

Код

Расшифровка кода

Описание

100

Continue

Код информирует клиента, что начальная часть

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

101

Switching Protocols

Сервер выполняет запрос клиента на переключение

протоколов в соответствии с указанием, переданным в поле Upgrade заголовка HTTP- запроса.

Таблица 4.5 – Коды ответа сервера при успешной обработке запроса

Код	Расшифровка кода	Описание
200	OK	Запрос успешно обработан, данные отправляются с учетом метода, которым был произведен запрос.
201	Created	Код используется при создании нового URI. В
		заголовке ответа сервером выдается поле Location, содержащее адрес размещения данных.
202	Accepted	Запрос принят к обработке, но обработка не завершена. Запрос может быть отклонен, когда его процесс его обработки будет запущен.
203	Non-Authoritative Information	Метаданные заголовка ответа не являются доступными с исходного сервера, но получены из локальной копии или с сервера третьей стороны.
204	No Content	Сервер обработал запрос, но необходимость отправлять тело ответа отсутствует. При получении этого кода браузер не должен обновлять документ. Код используется в первую очередь для обработки действий, выполненных над активными изображениями.
205	Reset Content	Клиент должен очистить форму (документ), вызвавшую отправку запроса. Данный код используется для CGI-скриптов, требующих ввод данных.
206	Partial Content	Сервер отправляет часть документа, запрошенного клиентом, в соответствии с указанным клиентом диапазоном байт запрошенных данных. Используется для возобновления скачивания документов.

Таблица 4.6 – Коды ответа сервера, связанные с перенаправлением запроса

Код	Расшифровка кода	Описание
300	Multiple Choices	Запрошенный ресурс соответствует нескольким документам. Ответ сервера (за исключением запросов по методу HEAD) должен включать перечень ресурсов, из которых может быть выбран наиболее устраивающий. В то же время спецификация HTTP/1.1 не определяет стандартов для автоматического определения ресурса.
301	Moved Permanently	Запрошенный документ соответствует новому постоянному URI, который должен быть указать в поле Location заголовка ответа сервера. При последующих запросах документа следует использовать указанный URI.
302	Found	Запрошенный документ временно находится по указанному в поле Location заголовка ответа сервера адресу.
303	See Other	Запрошенный документ может быть найден по URI, указанному в поле Location заголовка ответа сервера адресу и должен быть получен с использованием метода GET.
304	Not Modified	Документ не изменялся со времени, указанного в поле If-Modified-Since заголовка запроса клиента. Ответ сервера с таким кодом не содержит тела документа, клиент должен использовать хранящуюся у него локальную копию.
305	Use Proxy	Доступ к запрошенному документу должен быть произведен через прокси-сервер, адрес которого указывается в поле Location заголовка ответа сервера.
306	(Unused)	Код использовался в предыдущих версиях протокола, но не используется с момента выхода спецификации HTTP/1.1. Код является зарезервированным.
307	Temporary Redirect	Запрошенный документ временно находится по указанному в поле Location заголовка ответа сервера адресу.

Таблица 4.7 – Коды ответа сервера, связанные с ошибкой на стороне клиента

Код	Расшифровка кода	Описание
400	Bad Request	Запрос не понят сервером из-за ошибок в синтаксисе.
401	Unauthorized	Для обработки запроса требуется аутентификация пользователя на сервере. /ссылка http access authentication/
402	Payment Required	Зарезервирован для будущего использования.
403	Forbidden	Доступ запрещен. Наиболее частые причины ответа с таким кодом – ошибки при авторизации на сервере и запрос листинга каталога, в то время как он запрещен конфигурацией сервера.
404	Not Found	Документ по запрошенному URI не найден. Причины отсутствия документа не указываются. В случае, если серверу известно, что документ по этому адресу не будет находиться и в дальнейшем, серверу следует использовать код 410 (Gone).
405	Method Not Allowed	Использование метода, примененного для запроса документа, не допускается. В поле Allow заголовка ответа сервера указывается перечень допустимых методов.
406	Not Acceptable	Документ существует по запрошенному URI, но его формат не соответствует списку поддерживаемых клиентом (на основании заголовка запроса, отправленного клиентом).
407	Proxy Authentication Required	Этот код похож на код 401 (Unauthorized), но показывает, что клиент должен произвести аутентификацию на прокси-сервере.
408	Request Timeout	Клиентом не был передан запрос в течение установленного сервером времени. Запрос может быть повторен клиентом позже.
409	Conflict	Запрос не может быть обработан из-за конфликта, связанного с текущим состоянием документа. Применение кода возможно только в тех случаях, когда клиент может разрешить конфликт и повторить запрос. Тело ответа должно содержать достаточно информации для того, чтобы пользователь мог распознать причины конфликта. Наиболее вероятно появление подобных конфликтов при использовании метода PUT.
410	Gone	Запрошенный ресурс не существует и навсегда удален с сервера.
411	Length Required	Сервер отказывает в обработке запроса без указания клиентом поля Content-Length в заголовке запроса.
412	Precondition Failed	Условие, заданное в одном или нескольких полях заголовка запроса, дает значение «ложь».
413	Request Entity Too Large	Тело запроса слишком велико и поэтому запрос не обрабатывается сервером.
414	Request-URI Too Long	Сервер отказывается обрабатывать запрос, так как URI запрошенного документа имеет чрезмерную длину.
415	Unsupported Media Type	Сервер отказывается обрабатывать запрос, так как тело запроса имеет не поддерживаемый сервером тип данных.
416	Requested Range Not Satisfiable	Сервер не обрабатывает запрос, так как запрошенный диапазон байт является неприемлемым.
417	Expectation Failed	Значение, переданное в поле Expect запроса, не может быть удовлетворено сервером.

Таблица 4.8 – Коды ответа, связанные с ошибкой на стороне сервера

Код	Расшифровка кода	Описание
500	Internal Server Error	При обработке запроса на сервере произошла ошибка. Наиболее часто встречающиеся причины – ошибка в CGI-скриптах или конфигурации самого сервера.
501	Not Implemented	Сервером не поддерживаются функции, необходимые для выполнения запроса.
502	Bad Gateway	Сервер, работающий как шлюз или прокси, получил недопустимый ответ от другого сервера во время попытки обработки запроса.
503	Service Unavailable	Сервер не может обработать запрос из-за временной перегрузки или технических работ на сервере. Если серверу известно, когда будет возобновлен доступ, сервер может выдать в заголовке поле Retry-After, в противном случае клиент должен обрабатывать ответ так же, как при получении кода ответа 500.
504	Gateway Timeout	Сервер, работающий как шлюз или прокси, не получил необходимого для обработки запроса ответа от другого сервера.
505	HTTP Version Not Supported	Сервер не поддерживает версию протокола HTTP, указанную в запросе. В теле ответа сервера должна присутствовать информация о причинах и доступных версиях.

Присоединиться к общению