Что такое HTTP и как он работает. Простым языком об HTTP

Цель лекции: сформировать представление о функционировании протокола HTTP/HTTPS.

HTTP (HyperText Transfer Protocol) – один из наиболее важных протоколов, который обеспечивает передачу данных через интернет. Протокол HTTP находится на седьмом, прикладном уровне модели OSI и работает на основе протокола TCP.

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

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

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

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

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

HTTP-запрос формируется на клиенте и отправляется на сервер с целью получения информации от него. В нем содержится информация о ресурсе, который необходимо загрузить, а также дополнительные сведения. Первая строка содержит метод запроса (который мы рассмотрим далее в этой лекции), имя ресурса (с указанием относительного пути на сервере), а также версию протокола. Например, вид приветственной строки может быть определен как "GET /images/corner1.png HTTP/1.1 ". Такой запрос обращается к серверу с требованием выдать методом GET изображение, расположенное в папке "images " и имеющее название "corner1.png ". HTTP-заголовки имеют важное значение для HTTP-запроса, поскольку в них указывается уточняющая информация о запросе – версия браузера, возможности клиента принимать сжатое содержимое, возможности кэширования и другие важные параметры, которые могут влиять на формирование ответа. В теле HTTP-запроса обычно содержится информация, которую необходимо передать на сервер. Например, если требуется загрузить файл на сервер, то содержимое файла будет находится в теле HTTP-запроса. Однако, размещение данных в теле HTTP-запроса допускается не для всех HTTP-методов. Например, тело HTTP-запроса всегда пустое, если используется метод GET . Таким образом, стандартный HTTP-запрос может выглядеть следующим образом.

В приведенном HTTP-запросе клиент обращается к серверу "microsoft.com ", запрашивает ресурс "images/corner.png " и указывает, что он способен принимать сжатое содержимое по алгоритму "gzip " или "deflate ", его языком является английский язык и указывает версию своего браузера. Как было отмечено ранее, количество и набор заголовков может существенно отличаться. Можно привести другой пример HTTP-запроса.

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

HTTP-ответ генерируется веб-сервером в ответ на поступивший HTTP-запрос. По своей структуре он схож с HTTP-запросом, но имеет определенные отличия. Главное отличие содержится в первой строке. Вместо имени запрашиваемого ресурса и метода запроса в ней указывается статус ответа. Статус указывает на то, насколько успешно выполнился HTTP-запрос. Например, в случае, если документ найден на сервере и может быть выдан клиенту, то статус имеет значение "ОК ", которое говорит о том, что запрос выполнился успешно. Однако, могут появляться исключительные ситуации – например, документ отсутствует на сервере или у пользователя отсутствуют права на получение ресурса. Набор всевозможных статусных сообщений HTTP-ответа мы рассмотрим далее в этой лекции. Таким образом, первая строка HTTP-ответа может принимать значение "HTTP/1.1 200 OK ". HTTP-заголовки в HTTP-ответе также являются важным элементом. Они характеризуют содержимое, которое передается клиенту. Например, в этих HTTP-заголовках может содержаться информация о типе содержимого (HTML-документ, изображение и т.д.), длине содержимого (размер в байтах), дате модификации, режиме кэширования и др. Все эти заголовки влияют на способ отображения данных на клиенте, а также устанавливают правила хранения данных в клиентском кэше. Типичный вид HTTP-ответа может быть следующим.

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

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

Наиболее распространенными методами HTTP-запроса являются следующие типы методов:

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

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

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

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

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

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

По этой причине существует модификация этого протокола – HTTPS , т.е. протокол HTTP с поддержкой шифрования.

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

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

Краткие итоги

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

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

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

История развития

HTTP/0.9

Кроме обычного метода GET , различают ещё и . Условные запросы GET содержат заголовки If-Modified-Since , If-Match , If-Range и подобные. Частичные GET содержат в запросе Range . Порядок выполнения подобных запросов определён стандартами отдельно.

HEAD

Аналогичен методу GET , за исключением того, что в ответе сервера отсутствует тело. Запрос HEAD обычно применяется для извлечения метаданных , проверки наличия ресурса (валидация URL) и чтобы узнать, не изменился ли он с момента последнего обращения.

Заголовки ответа могут кэшироваться. При несовпадении метаданных ресурса с соответствующей информацией в кэше копия ресурса помечается как устаревшая.

POST

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

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

При результате выполнения 200 (Ok) в тело ответа следует включить сообщение об итоге выполнения запроса. Если был создан ресурс, то серверу следует вернуть ответ 201 (Created) с указанием URI нового ресурса в заголовке Location .

Сообщение ответа сервера на выполнение метода POST не кэшируется.

PUT

Применяется для загрузки содержимого запроса на указанный в запросе URI. Если по заданному URI не существовало ресурса, то сервер создаёт его и возвращает статус 201 (Created). Если же был изменён ресурс, то сервер возвращает 200 (Ok) или 204 (No Content). Сервер не должен игнорировать некорректные заголовки Content-* передаваемые клиентом вместе с сообщением. Если какой-то из этих заголовков не может быть распознан или не допустим при текущих условиях, то необходимо вернуть код ошибки 501 (Not Implemented).

Фундаментальное различие методов POST и PUT заключается в понимании предназначений URI ресурсов. Метод POST предполагает, что по указанному URI будет производиться обработка передаваемого клиентом содержимого. Используя PUT , клиент предполагает, что загружаемое содержимое соответствует находящемуся по данному URI ресурсу.

Сообщения ответов сервера на метод PUT не кэшируются.

PATCH

Аналогично PUT, но применяется только к фрагменту ресурса.

DELETE

Удаляет указанный ресурс.

TRACE

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

LINK

Устанавливает связь указанного ресурса с другими.

UNLINK

Убирает связь указанного ресурса с другими.

CONNECT

Преобразует соединение запроса в прозрачный TCP/IP туннель, обычно чтобы содействовать установлению защищенного SSL соединения через нешифрованный прокси.

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

Код состояния является частью первой строки ответа сервера. Он представляет собой целое число из трех арабских цифр . Первая цифра указывает на класс состояния. За кодом ответа обычно следует отделённая пробелом поясняющая фраза на английском языке, которая разъясняет человеку причину именно такого ответа. Примеры:

201 Webpage Created 403 Access allowed only for registered users 507 Insufficient Storage

Клиент узнаёт по коду ответа о результатах его запроса и определяет, какие действия ему предпринимать дальше. Набор кодов состояния является стандартом, и они описаны в соответствующих документах RFC . Введение новых кодов должно производиться только после согласования с IETF . Клиент может не знать все коды состояния, но он обязан отреагировать в соответствии с классом кода.

В настоящее время выделено пять классов кодов состояния.

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

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

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

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

Для запоминания значений кодов с 400 по 417 существуют приёмы иллюстративной мнемотехники

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

Заголовки

Тело сообщения

Тело HTTP сообщения (message-body), если оно присутствует, используется для передачи тела объекта, связанного с запросом или ответом. Тело сообщения (message-body) отличается от тела объекта (entity-body) только в том случае, когда применяется кодирование передачи, что указывается полем заголовка Transfer-Encoding.

Message-body = entity-body |

Поле Transfer-Encoding должно использоваться для указания любого кодирования передачи, примененного приложением в целях гарантирования безопасной и правильной передачи сообщения. Поле Transfer-Encoding - это свойство сообщения, а не объекта, и, таким образом, может быть добавлено или удалено любым приложением в цепочке запросов/ответов.

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

Присутствие тела сообщения в запросе отмечается добавлением к заголовкам запроса поля заголовка Content-Length или Transfer-Encoding. Тело сообщения (message-body) МОЖЕТ быть добавлено в запрос только когда метод запроса допускает тело объекта (entity-body).

Включается или не включается тело сообщения (message-body) в сообщение ответа зависит как от метода запроса, так и от кода состояния ответа. Все ответы на запрос с методом HEAD не должны включать тело сообщения (message-body), даже если присутствуют поля заголовка объекта (entity-header), заставляющие поверить в присутствие объекта. Никакие ответы с кодами состояния 1xx (Информационные), 204 (Нет содержимого, No Content), и 304 (Не модифицирован, Not Modified) не должны содержать тела сообщения (message-body). Все другие ответы содержат тело сообщения, даже если оно имеет нулевую длину.

Примеры диалогов HTTP

Обычный GET-запрос

Различают два основных типа согласований:

• Управляемое сервером (англ. Server-Driven ).
• Управляемое клиентом (англ. Agent-Driven ).

Одновременно могут быть использованы оба типа или каждый из них по отдельности.

В основной спецификации по протоколу (RFC 2616) также выделяется так называемое прозрачное согласование (англ. Transparent Negotiation ) как предпочтительный вариант комбинирования обоих типов. Последний механизм не следует путать с независимой технологией Transparent Content Negotiation (TCN, рус. Прозрачное согласование содержимого , см. RFC 2295), которая не является частью протокола HTTP, но может использоваться с ним. У обоих существенное различие в принципе работы и самом значении слова «прозрачное» (transparent). В спецификации по HTTP под прозрачностью подразумевается, что процесс не заметен для клиента и сервера, а в технологии TCN прозрачность означает доступность полного списка вариантов ресурса для всех участников процесса доставки данных.

Управляемое сервером

При наличии нескольких версий ресурса сервер может анализировать заголовки запроса клиента, чтобы выдать, по его мнению, наиболее подходящую. В основном анализируются заголовки Accept , Accept-Charset , Accept-Encoding , Accept-Languages и User-Agent . Серверу желательно включать в ответ заголовок Vary с указанием параметров, по которым различается содержимое по запрашиваемому URI.

Географическое положение клиента можно определить по удалённому IP-адресу . Это возможно за счёт того что IP-адреса, как и доменные имена , регистрируются на конкретного человека или организацию. При регистрации указывается регион, в котором будет использоваться желаемое адресное пространство. Эти данные общедоступны, и в Интернете можно найти соответствующие свободно распространяемые базы данных и готовые программные модули для работы с ними (следует ориентироваться на ключевые слова «Geo IP»).

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

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

• Сервер только предполагает, какой вариант наиболее предпочтителен для конечного пользователя, но не может знать точно, что именно нужно в данный момент (например, версия на русском языке или английском).
• Заголовков группы Accept передаётся много, а ресурсов с несколькими вариантами - мало. Из-за этого оборудование испытывает избыточную нагрузку.
• Общему кэшу создаётся ограничение возможности выдавать один и тот же ответ на идентичные запросы от разных пользователей.
• Передача заголовков Accept также может раскрывать некоторые сведения о его предпочтениях, таких как используемые языки, браузер, кодировка.

Управляемое клиентом

В данном случае тип содержимого определяется только на стороне клиента. Для этого сервер возвращает с кодом состояния 300 (Multiple Choices) или 406 (Not Acceptable) список вариантов, среди которых пользователь выбирает подходящий. Управляемое клиентом согласование хорошо, когда содержимое различается по самым частым параметрам (например, по языку и кодировке) и используется публичный кэш.

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

Прозрачное согласование

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

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

Множественное содержимое

Протокол HTTP поддерживает передачу нескольких сущностей в пределах одного сообщения. Причём сущности могут передаваться не только в виде одноуровневой последовательности, но в виде иерархии с вложением элементов друг в друга. Для обозначения множественного содержимого используются медиатипы multipart/* . Работа с такими типами осуществляется по общим правилам, описанным в RFC 2046 (если иное не определено конкретным медиа типом). Если получателю не известно как работать с типом, то он обрабатывает его так же, как multipart/mixed .

Параметр boundary означает разделитель между различными типами передаваемых сообщений. Например передаваемый из формы параметр DestAddress передает значение e-mail адреса, а последущий за ним элемент AttachedFile1 отправляет двоичное содержимое изображения формата.jpg

Со стороны сервера сообщения со множественным содержимым могут посылаться в ответ на при запросе нескольких фрагментов ресурса. В этом случае используется медиа тип multipart/byteranges .

Со стороны клиента при отправке HTML -формы чаще всего пользуются методом POST . Типичный пример: страницы отправки электронных писем со вложенными файлами. При отправке такого письма браузер формирует сообщение типа multipart/form-data , интегрируя в него как отдельные части, введённые пользователем, тему письма, адрес получателя, сам текст и вложенные файлы:

POST /send-message.html HTTP/1.1 Host: mail.example.com Referer: http://mail.example.com/send-message.html User-Agent: BrowserForDummies/4.67b Content-Type: multipart/form-data; boundary="Asrf456BGe4h" Content-Length: (суммарный объём, включая дочерние заголовки) Connection: keep-alive Keep-Alive: 300 (пустая строка) (отсутствующая преамбула) --Asrf456BGe4h Content-Disposition: form-data; name="DestAddress" (пустая строка) [email protected] --Asrf456BGe4h Content-Disposition: form-data; name="MessageTitle" (пустая строка) Я негодую --Asrf456BGe4h Content-Disposition: form-data; name="MessageText" (пустая строка) Привет, Василий! Твой ручной лев, которого ты оставил у меня на прошлой неделе, разодрал весь мой диван. Пожалуйста, забери его скорее! Во вложении две фотки с последствиями. --Asrf456BGe4h Content-Disposition: form-data; name="AttachedFile1"; filename="horror-photo-1.jpg" Content-Type: image/jpeg (пустая строка) (двоичное содержимое первой фотографии) --Asrf456BGe4h Content-Disposition: form-data; name="AttachedFile2"; filename="horror-photo-2.jpg" Content-Type: image/jpeg (пустая строка) (двоичное содержимое второй фотографии) --Asrf456BGe4h-- (отсутствующий эпилог)

В примере в заголовках Content-Disposition параметр name соответствует атрибуту name в HTML-тегах и . Параметр filename равен исходному имени файла на компьютере пользователя. Более подробная информация о формировании HTML-форм и вложении файлов в RFC 1867 .</p> <h2><span>Особенности протокола </span></h2> <p>Большинство протоколов предусматривают установление TCP-сессии, в ходе которой один раз происходит авторизация, и <a href="/status-eksport-iz-strany-otpravleniya-varianty-dalneishih-deistvii.html">дальнейшие действия</a> выполняются в контексте этой авторизации. HTTP же устанавливает отдельную TCP-сессию на каждый запрос; в более поздних версиях HTTP было разрешено делать несколько запросов в ходе одной TCP-сессии, но браузеры обычно запрашивают только страницу и включённые в неё объекты (картинки, каскадные стили и т. п.), а затем сразу разрывают TCP-сессию. Для поддержки авторизованного (неанонимного) доступа в HTTP используются cookies ; причём такой способ авторизации позволяет сохранить сессию даже после перезагрузки клиента и сервера.</p> <p>При доступе к данным по FTP или по файловым протоколам тип файла (точнее, тип содержащихся в нём данных) определяется по расширению имени файла, что не всегда удобно. HTTP перед тем, как передать сами данные, передаёт заголовок «Content-Type: тип/подтип», позволяющую клиенту однозначно определить, каким образом обрабатывать присланные данные. Это особенно важно при работе с CGI-скриптами, когда расширение имени файла указывает не на тип присылаемых клиенту данных, а на необходимость запуска <a href="/avtomaticheskaya-sinhronizaciya-failov-programma-dlya-sinhronizacii.html">данного файла</a> на сервере и отправки клиенту результатов работы программы, записанной в этом файле (при этом один и тот же файл в зависимости от аргументов запроса и своих собственных соображений может порождать ответы <a href="/pochemu-ne-vklyuchaetsya-noutbuk-msi-noutbuk-msi-ne-zagruzhaetsya-perechen.html">разных типов</a> - в простейшем случае картинки в разных форматах).</p> <p>Кроме того, HTTP позволяет клиенту прислать на сервер параметры, которые будут переданы запускаемому CGI-скрипту. Для этого же в HTML были введены формы.</p> <p>Перечисленные особенности HTTP позволили создавать поисковые машины (первой из которых стала AltaVista, созданная фирмой DEC), форумы и Internet-магазины. Это коммерциализировало Интернет, появились компании, основным полем деятельности которых стало предоставление доступа в Интернет (провайдеры) и создание сайтов.</p> <h2>Примечания </h2> <h2>См. также </h2> <h2>Ссылки </h2> <table class="navbox collapsible autocollapse nowraplinks" style="margin:auto;;"><tr><th colspan="2" style="text-align:center;width:100%;"></th></tr></table> <p>Вашему вниманию предлагается описание основных аспектов протокола HTTP - <a href="/setevye-protokoly-protokoly-lokalnyh-setei.html">сетевого протокола</a>, с начала 90-х и по сей день позволяющего вашему браузеру загружать веб-страницы. Данная статья написана для тех, кто только начинает работать с компьютерными сетями и заниматься разработкой <a href="/kak-voiti-v-yandeks-disk-s-razlichnyh-ustroistv-oblako-yandeks-disk.html">сетевых приложений</a>, и кому пока что сложно самостоятельно читать официальные спецификации.</p><p><b>HTTP </b> - широко распространённый протокол передачи данных, изначально предназначенный для передачи гипертекстовых документов (то есть документов, которые могут содержать ссылки, позволяющие организовать переход к другим документам).</p><p>Аббревиатура HTTP расшифровывается как <i>HyperText Transfer Protocol </i>, «протокол передачи гипертекста». В соответствии со спецификацией OSI , HTTP является протоколом прикладного (верхнего, 7-го) уровня. Актуальная на данный момент версия протокола, HTTP 1.1, описана в спецификации RFC 2616 .</p><p>Протокол HTTP предполагает использование клиент-серверной структуры передачи данных. Клиентское приложение формирует запрос и отправляет его на сервер, после чего серверное программное обеспечение обрабатывает <a href="/kak-poluchit-dannye-iz-zaprosa-sql-v-microsoft-access-vba-kak-poslat-zapros-k.html">данный запрос</a>, формирует ответ и передаёт его обратно клиенту. После этого <a href="/klientskoe-prilozhenie-maksima-taksi-voditelskie-terminaly-maxima.html">клиентское приложение</a> может продолжить отправлять другие запросы, которые будут обработаны аналогичным образом.</p><p>Задача, которая традиционно решается с помощью протокола HTTP - обмен данными между <a href="/prilozhenie-polzovatelskii-interfeis-zablokirovano-z3.html">пользовательским приложением</a>, осуществляющим доступ к веб-ресурсам (обычно это веб-браузер) и веб-сервером. На данный момент именно благодаря протоколу HTTP обеспечивается работа Всемирной паутины.<br><br> Также HTTP часто используется как протокол передачи информации для других протоколов <a href="/prikladnoi-informacionnyi-uroven-prikladnye-resursy.html">прикладного уровня</a>, таких как SOAP, XML-RPC и WebDAV. В таком случае говорят, что протокол HTTP используется как «транспорт».</p><p>API многих <a href="/ispolzovanie-po-s-otkrytym-ishodnym-kodom-dlya-sozdaniya-uspeshnyh.html">программных продуктов</a> также подразумевает использование HTTP для передачи данных - сами данные при этом могут иметь любой формат, например, XML или JSON.</p><p>Как правило, передача данных по протоколу HTTP осуществляется через TCP/IP-соединения. Серверное программное обеспечение при этом обычно использует TCP-порт 80 (и, если порт не указан явно, то обычно клиентское программное обеспечение по умолчанию использует именно 80-й порт для открываемых HTTP-соединений), хотя может использовать и любой другой.</p><h4>Как отправить HTTP-запрос?</h4> Самый простой способ разобраться с протоколом HTTP - это попробовать обратиться к какому-нибудь веб-ресурсу вручную. Представьте, что вы браузер, и у вас есть пользователь, который очень хочет прочитать статьи Анатолия Ализара.<p>Предположим, что он ввёл в <a href="/kak-v-firefox-peremestit-vkladki-vniz-pod-adresnuyu-stroku-kak.html">адресной строке</a> следующее:</p><p>Http://alizar.habrahabr.ru/ </p><p>Соответственно вам, как веб-браузеру, теперь необходимо подключиться к веб-серверу по адресу alizar.habrahabr.ru.</p><p>Для этого вы можете воспользоваться любой подходящей утилитой <a href="/kak-otkryt-komandnuyu-stroku-cmd-kak-vyzvat-komandnuyu-stroku-zapusk.html">командной строки</a>. Например, telnet:</p><p>Telnet alizar.habrahabr.ru 80 </p><p>Сразу уточню, что если вы вдруг передумаете, то нажмите Ctrl + «]», и затем ввод - это позволит вам закрыть HTTP-соединение. Помимо telnet можете попробовать nc (или ncat) - по вкусу.</p><p>После того, как вы подключитесь к серверу, нужно отправить HTTP-запрос. Это, кстати, очень легко - HTTP-запросы могут состоять всего из двух строчек.</p><p>Для того, чтобы сформировать HTTP-запрос, необходимо составить стартовую строку, а также задать по крайней мере один заголовок - это заголовок Host, который является обязательным, и должен присутствовать в каждом запросе. Дело в том, что преобразование доменного имени в IP-адрес осуществляется на стороне клиента, и, соответственно, когда вы открываете TCP-соединение, то удалённый сервер не обладает никакой информацией о том, какой именно адрес использовался для соединения: это мог быть, например, адрес alizar.habrahabr.ru, habrahabr.ru или m.habrahabr.ru - и во всех этих случаях ответ может отличаться. Однако фактически <a href="/chto-pisat-komandnoi-zapusk-administrativnyh-instrumentov-iz-cmd.html">сетевое соединение</a> во всех случаях открывается с узлом 212.24.43.44, и даже если первоначально при открытии соединения был задан не этот IP-адрес, а какое-либо <a href="/chto-takoe-domen-kak-proizvoditsya-registraciya-domennogo-imeni-domen.html">доменное имя</a>, то сервер об этом никак не информируется - и именно поэтому этот адрес необходимо передать в заголовке Host.</p><p>Стартовая (начальная) строка запроса для HTTP 1.1 составляется по следующей схеме:</p><p>Например (такая <a href="/sdelat-startovoi-strokoi-kak-sdelat-startovoi-stranicei-yandeks.html">стартовая строка</a> может указывать на то, что запрашивается <a href="/yandeks-glavnaya-stranica-ustanovit-kak-postavit-startovuyu.html">главная страница</a> сайта):</p><p>Ну и, конечно, не забывайте, что любая технология становится намного проще и понятнее тогда, когда вы фактически начинаете ей пользоваться.</p><p>Удачи и плодотворного обучения!<br></p><p>Теги: Добавить метки</p> <p>Позволяющий получать различные ресурсы, например HTML-документы. Протокол HTTP лежит в основе обмена данными в Интернете. HTTP является протоколом клиент-серверного взаимодействия, что означает инициирование запросов к серверу самим получателем, обычно веб-браузером. Полученный итоговый документ будет реконструирован из различных субдокументов, например, из отдельно полученного текста, описания структуры документа, изображений, видео-файлов, скриптов и многого другого.</p> <p>Клиенты и серверы взаимодействуют, обмениваясь <a href="/kak-ukrasit-stranicu-gruppy-v-vk-lichnye-soobshcheniya-soobshchestva.html">индивидуальными сообщениями</a> (а не потоком данных). Сообщения, отправленные клиентом, обычно веб-браузером, называются <i>запросами </i>, а сообщения, отправленные сервером, называются <i>ответами </i>.</p> <p><img src='https://i0.wp.com/mdn.mozillademos.org/files/13673/HTTP%20&%20layers.png' width="100%" loading=lazy>Хотя HTTP был разработан еще в начале 1990-х годов, за счет своей расширяемости в дальнейшем он все время совершенствовался. HTTP является протоколом прикладного уровня, который чаще всего использует возможности другого протокола - TCP (или TLS - защищённый TCP) - для пересылки своих сообщений, однако любой другой надежный транспортный протокол теоретически может быть использован для доставки таких сообщений. Благодаря своей расширяемости, он используется не только для получения клиентом гипертекстовых документов либо изображений и видео, но и для передачи контента серверам, например, с помощью HTML-форм. HTTP также может быть использован для получения только частей документа с целью обновления веб-страницы по запросу.</p> <h2>Компоненты систем, основанных на HTTP</h2> <p>HTTP - это клиент-серверный протокол, то есть запросы отправляются какой-то одной стороной - юзер-агентом (user-agent) (либо прокси вместо него). Чаще всего в качестве юзер-агента выступает веб-браузер, но им может быть кто угодно, например, робот, путешествующий по Сети для пополнения и обновления данных индексации веб-страниц для поисковых систем.</p> <p>Каждый индивидуальный запрос (англ. <i>request </i>) отправляется серверу, который обрабатывает его и возвращает ответ (англ. <i>response </i>). Между этими запросами и ответами существуют многочисленные посредники, называемые прокси , которые выполняют различные операции и работают как шлюзы или кэш , например.</p> <p>В реальности, между браузером и сервером гораздо больше различных устройств-посредников, которые играют какую-либо роль в обработке запроса: роутеры, модемы и так далее. Благодаря тому, что Сеть построена на основе системы уровней (слоёв) взаимодействия, эти посредники "спрятаны" на сетевом и транспортном уровнях. В этой системе уровней HTTP занимает самый <a href="/domen-lv-kakaya-strana-spisok-nacionalnyh-domenov-verhnego.html">верхний уровень</a>, который называется "прикладным" (или "уровнем приложений"). Знания об уровнях сети, таких как представительский, сеансовый, транспортный, сетевой, канальный и физический, имея важное значение для понимания работы сети и диагностики <a href="/pochemu-dns-server-nedostupen-kak-reshit-problemu-vozmozhnye.html">возможных проблем</a>, не требуются для описания и понимания HTTP.</p> <h3>Клиент: юзер-агент</h3> <p>Юзер-агент - это любой инструмент или устройство, действующие от лица пользователя. Эта роль преимущественно принадлежит веб-браузеру; в некоторых случаях юзер-агентами выступают программы, которые используются инженерами и веб-разработчиками для отладки своих приложений.</p> <p>Браузер <b>всегда </b> является той сущностью, которая инициирует запрос. Сервер никогда этого не делает (хотя за многие годы существования сети были созданы механизмы, которые могут симулировать запросы со стороны сервера).</p> <p>Чтобы отобразить веб страницу, браузер отправляет начальный запрос для получения HTML-документа этой страницы. После этого браузер анализирует этот документ, и запрашивает <a href="/13-kakie-rasshireniya-mogut-imet-programmnye-prilozheniya-opredelenie-faila-tip.html">дополнительные файлы</a>, необходимые для отбражения содержания веб-страницы (исполняемые скрипты, информацию о макете страницы - CSS таблицы стилей, дополнительные ресурсы в виде изображений и видео-файлов). Далее браузер соединяет все эти ресурсы для отображения их пользователю в виде единого документа - веб-страницы. Скрипты, выполняемые самим браузером, могут получать по сети дополнительные ресурсы на последующих этапах обработки веб-страницы, и браузер соотвествующим образом обновляет представление этой страницы для пользователя.</p> <p>Веб-страница является гипертекстовый документом. Это означает, что некоторые части отображаемого текста являются ссылками, которые могут быть активированы (обычно нажатием кнопки мыши) с целью получения и соответственно отображения новой веб-страницы. Это позволяет пользователю направлять своего юзер-агента, осуществляя навигацию по Сети. Браузер транслирует эти "направления движения" в HTTP-запросы и в дальнейшем интерпретирует HTTP-ответы в понятном для пользователя виде.</p> <h3>Веб-сервер</h3> <p>На другой стороне <a href="/kommunikacionnyi-process-i-kanaly-peredachi-informacii-sposoby-peredachi.html">коммуникационного канала</a> расположен сервер, который обслуживает (англ. <i>serve </i>) пользователя, предоставляя ему документы по запросу. С точки зрения конечного пользователя, сервер всегда является некой одной <a href="/eksport-i-import-virtualnoi-mashiny-hyper-v-eksport-virtualnyh-mashin.html">виртуальной машиной</a>, полностью или частично генерирующей документ, хотя фактически он может быть группой серверов, между которыми балансируется нагрузка, то есть перераспределяются запросы различных пользователей, либо сложным <a href="/informacionnaya-sistema-programmnoe-obespechenie-informacionnoi-sistemy.html">программным обеспечением</a>, опрашивающим другие компьютеры (такие как кэширующие серверы, серверы баз данных, серверы приложений <a href="/vse-o-e-commerce-dlya-nachinayushchih-elektronnaya-kommerciya-kak-nisha-dlya-biznesa.html">электронной коммерции</a> и другие).</p> <p>Сервер не обязательно расположен на одной машине, и наоборот - несколько серверов могут быть расположены (хоститься) на одной и той же машине. В соответствии с версией HTTP/1.1 и имея Host заголовок, они даже могут делить тот же самый IP-адрес.</p> <h3>Прокси</h3> <p>Между веб-браузером и сервером находятся большое количество сетевых узлов передающих HTTP сообщения. Из за слоистой структуры, большинство из них оперируют также на транспортном сетевом или <a href="/urovni-fizicheskii-setevoi-kanalnyi-kak-rabotaet-model-osi.html">физическом уровнях</a>, становясь прозрачным на HTTP слое и потенциально снижая производительность. Эти операции на уровне приложений называются <u><b>прокси </b> </u>. Они могут быть прозрачными, или нет, (изменяющие запросы не пройдут через них), и способны исполнять множество функций:</p> <ul><li>caching (кеш может быть публичным или приватными, как кеш браузера)</li> <li>фильтрация (как сканирование антивируса, <a href="/bilain-pin-kod-roditelskoi-usluga-bilain-roditelskii.html">родительский контроль</a>, …)</li> <li>выравнивание нагрузки (позволить нескольким серверам обслуживать разные запросы)</li> <li>аутотентификация (контролировать доступом к разным ресурсам)</li> <li>протоколирование (разрешение на хранение истории операций)</li> </ul><h2>Основные аспекты HTTP</h2> <h3>HTTP - прост</h3> <p>Даже с большей сложностью, введенной в HTTP/2 путем инкапсуляции HTTP-сообщений в фреймы, HTTP, как правило, прост и удобен для восприятия человеком. HTTP-сообщения могут читаться и пониматься людьми, обеспечивая более легкое тестирование разработчиков и уменьшенную сложность для новых пользователей.</p> <h3>HTTP - расширяемый</h3> <p>Введенные в HTTP/1.0 HTTP-заголовки сделали этот протокол легким для расширения и экспериментирования. Новая функциональность может быть даже введена простым соглашением между клиентом и сервером о семантике нового заголовка.</p> <h3>HTTP не имеет состояния, но имеет сессию</h3> <p>HTTP не имеет состояния: не существует связи между двумя запросами, которые последовательно выполняются по одному соединению. Из этого немедленно следует возможность проблем для пользователя, пытающегося взаимодействовать с определенной страницей последовательно, например, при использовании корзины в электронном магазине. Но хотя ядро HTTP не имеет состояния, куки позволяют использовать сессии с сохранением состояния. Используя расширяемость заголовков, куки добавляются к рабочему потоку, позволяя сессии на каждом HTTP-запросе делиться некоторым контекстом, или состоянием.</p> <h3>HTTP и соединения</h3> <p>Содинение управляется на транспортном уровне, и потому принципиально выходит за границы HTTP. Хотя HTTP не требует, чтобы базовый транспортного протокол был основан на соединениях, требуя только <i>надёжность </i>, или отсутствие потерянных сообщений (т.е. как минимум представление ошибки). Среди двух наиболее распространенных транспортных протоколов Интернета, TCP надёжен, а UDP -- нет. HTTP впоследствии полагается на стандарт TCP, являющийся основанным на соединениях, несмотря на то, что соединение не всегда требуется.</p> <p>HTTP/1.0 открывал TCP-соединение для каждого обмена запросом/ответом, имея два важных недостатка: открытие соединения требует нескольких обменов сообщениями, и потому медленно, хотя становится более эффективным при отправке нескольких сообщений, или при регулярной отправке сообщений: <i>теплые </i> соединения более эффективны, чем <i>холодные </i>.</p> <p>Для смягчения этих недостатков, HTTP/1.1 предоставил конвеерную обработку (которую оказалось трудно реализовать) и устойчивые соединения: лежащее в <a href="/prikladnye-servisy-setei-tcp-ip-snmp-protokol-osnovy.html">основе TCP</a> соединение можно частично контролировать через заголовок Connection . HTTP/2 сделал следующий шаг, добавив мультиплексирование сообщений через простое соединение, помогающее держать соединение теплым и более эффективным.</p> <p>Проводятся эксперименты по разработке лучшего <a href="/transportnye-protokoly---udp-smotret-chto-takoe-udp-v-drugih.html">транспортного протокола</a>, более подходящего для HTTP. Например, Google эксперементирует с QUIC , которая основана на UDP, для предоставления более надёжного и эффективного транспортного протокола.</p> <h2>Чем можно управлять через HTTP</h2> <p>Естественная расширяемость HTTP со временем позволила большее управление и функциональность Сети. Кэш и методы аутентификации были ранними функциями в истории HTTP. Способность ослабить первоначальные ограничения, напротив, была добавлена в 2010-е.</p> <p>Ниже перечислены <a href="/svyaz-mezhdu-impulsnoi-i-peredatochnoi-harakteristiki-obshchie-svoistva.html">общие функции</a>, управляемые с HTTP.</p> <ul><li><i> </i><br> Сервер может инструктировать прокси и клиенты: что и как долго кэшировать. Клиент может инструктировать прокси промежуточных кэшей игнорировать хранимые документы.</li> <li><i>Ослабление ограничений источника </i><br> Для предотвращения шпионских и других, нарушающих приватность, вторжений, веб-браузер обчеспечивает строгое разделеление между веб-сайтами. Только страницы из<b> того же источника </b> могут получить доступ к информации на веб-странице. Хотя такие ограничение нагружают сервер, заголовки HTTP могут ослабить строгое разделение на стороне сервера, позволяя документу стать частью информации с различных доменов (по причинам безопасности).</li> <li><i>Аутентификация </i><br> Некоторые страницы доступны только специальным пользователям. Базовая аутентификация может предоставляться через HTTP, либо через использование заголовка WWW-Authenticate и подобных ему, либо с помощью настройки спецсессии, используя куки.</li> <li><i>Прокси и тунелирование </i><br> Серверы и/или клиенты часто располагаются в интранете, и скрывают свои истинные IP-адреса от других. <a href="/connection-closed-v-pubg-chto-delat-s-etoi-oshibkoi-http-zaprosy-my-vse.html">HTTP запросы</a> идут через прокси для пересечения этого сетевого барьера. Не все прокси -- HTTP прокси. SOCKS-протокол, например, оперирует на более низком уровне. Другие, как, например, ftp, могут быть обработаны этими прокси.</li> <li><i>Сессии </i><br> Использование <a href="/chto-takoe-faily-cookies-kuki-http-cookie-gde-nahodyatsya-i-hranyatsya-cookies.html">HTTP кук</a> позволяет связать запрос с состоянием на сервере. Это создает сессию, хотя ядро HTTP -- протокол без состояния. Это полезно не только для корзин в интернет-магазинах, но также для любых сайтов, позволяющих пользователю настроить выход.</li> </ul><h2>HTTP поток</h2> <p>Когда клиент хочет взаимодействовать с сервером, являясь конечным сервером или промежуточным прокси, он выполняет следующие шаги:</p> <ol><li>Открытие TCP соединения: TCP-соедиенение будет использоваться для отправки запроса или запросов, и получения ответа. Клиент может открыть новое соединение, переиспользовать существующее, или открыть несколько TCP-соединений к серверу.</li> <li>Отправка HTTP-сообщения: HTTP-собщения (до HTTP/2) -- человеко-читаемо. Начиная с HTTP/2, простые сообщения инкапсилуруются во фреймы, делая невозможным их чтения напрямую, но принципиально остаются такими же. GET / HTTP/1.1 Host: сайт Accept-Language: fr</li> <li>Читает ответ от сервера: HTTP/1.1 200 OK Date: Sat, 09 Oct 2010 14:28:02 GMT Server: Apache Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT ETag: "51142bc1-7449-479b075b2891b" Accept-Ranges: bytes Content-Length: 29769 Content-Type: text/html <!DOCTYPE html... (here comes the 29769 bytes of the requested web page)</li> <li>Закрывает или переиспользует соединение для дальнейщих запросов.</li> </ol><p>Если активирован HTTP-конвеер, несколько запросов могут быть отправлены без ожидания получения первого ответа целиком. HTTP-конвеер тяжело внедряется в существующие сети, где старые куски ПО сосуществуют с современными версиями. HTTP-конвеер был заменен в HTTP/2 на более надежные мультиплексивные запросы во фрейме.</p> <h2>HTTP сообщения</h2> <p>HTTP/1.1 и более ранние HTTP сообщения человеко-читаемы. В версии HTTP/2 эти сообщения встроены в новую бинарную структуру, фрейм, позволяющий оптимизации, такие как компрессия заголовков и мультиплексирование. Даже если часть оригинального HTTP сообщения отправлена в этой версии HTTP, семантика каждого сообщения не изменяется и клиент воссоздаёт (виртуально) оригинальный HTTP-запрос. Это также полезно для понимания HTTP/2 сообщений в формате HTTP/1.1.</p> <p>HTTP (HyperText Transfer Protocol - протокол передачи гипертекста) был разработан как основа World Wide Web.</p><p>Работа по протоколу HTTP происходит следующим образом: программа-клиент устанавливает TCP-соединение с сервером (стандартный номер порта-80) и выдает ему HTTP-запрос. Сервер обрабатывает этот запрос и выдает HTTP-ответ клиенту.</p><h3>Структура HTTP-запроса</h3> <p>HTTP-запрос состоит из заголовка запроса и тела запроса, разделенных пустой строкой. Тело запроса может отсутствовать.</p><p>Заголовок запроса состоит из главной (первой) строки запроса и последующих строк, уточняющих запрос в главной строке. Последующие строки также могут отсутствовать.</p><p>Запрос в главной строке состоит из трех частей, разделенных пробелами:</p><p><b>Метод </b> (иначе говоря, команда HTTP):</p><p><b>GET </b> - запрос документа. Наиболее часто употребляемый метод; в HTTP/0.9, говорят, он был единственным.</p><p><b>HEAD </b> - запрос заголовка документа. Отличается от GET тем, что выдается только заголовок запроса с информацией о документе. Сам документ не выдается.</p><p><b>POST </b> - этот метод применяется для передачи данных CGI-скриптам. Сами данные следуют в последующих строках запроса в виде параметров.</p><p><b>PUT </b> - разместить документ на сервере. Насколько я знаю, используется редко. Запрос с этим методом имеет тело, в котором передается сам документ.</p><p><b>Ресурс </b> - это путь к определенному файлу на сервере, который клиент хочет получить (или разместить - для метода PUT). Если ресурс - просто какой-либо файл для считывания, сервер должен по этому запросу выдать его в теле ответа. Если же это путь к какому-либо CGI-скрипту, то сервер запускает скрипт и возвращает результат его выполнения. Кстати, благодаря такой унификации ресурсов для клиента практически безразлично, что он представляет собой на сервере.</p><p><b>Версия протокола </b>-версия протокола HTTP, с которой работает клиентская программа.</p><p>Таким образом, простейший HTTP-запрос может выглядеть следующим образом:</p><p>Здесь запрашивается корневой файл из корневой директории web-сервера.</p><p>Строки после главной строки запроса имеют следующий формат:</p><p><b>Параметр: значениe </b>.</p><p>Таким образом задаются параметры запроса. Это является необязательным, все строки после главной строки запроса могут отсутствовать; в этом случае сервер принимает их значение по умолчанию или по результатам предыдущего запроса (при работе в режиме Keep-Alive).</p><p>Перечислю некоторые наиболее употребительные параметры HTTP-запроса:</p><p><b>Connection </b> (соединение)- может принимать значения Keep-Alive и close. Keep-Alive ("оставить в живых") означает, что после выдачи данного документа соединение с сервером не разрывается, и можно выдавать еще запросы. Большинство браузеров работают именно в режиме Keep-Alive, так как он позволяет за одно соединение с сервером "скачать" html-страницу и рисунки к ней. Будучи однажды установленным, режим Keep-Alive сохраняется до первой ошибки или до явного указания в очередном запросе Connection: close. <br> close ("закрыть") - соединение закрывается после ответа на данный запрос.</p><p><b>User-Agent </b> - значением является "кодовое обозначение" браузера, например:</p><p>Mozilla/4.0 (compatible; MSIE 5.0; Windows 95; DigExt)</p><p><b>Accept </b> - список поддерживаемых браузером типов содержимого в порядке их предпочтения данным браузером, например для моего IE5:</p><p>Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */*</p><p>Это, очевидно, нужно для случая, когда сервер может выдавать один и тот же документ в разных форматах.</p><p>Значение этого параметра используется в основном CGI-скриптами для формирования ответа, адаптированного для данного браузера.</p><p><b>Referer </b> - URL, с которого перешли на этот ресурс.</p><p><b>Host </b> - имя хоста, с которого запрашивается ресурс. Полезно, если на сервере имеется несколько виртуальных серверов под одним IP-адресом. В этом случае имя виртуального сервера определяется по этому полю.</p><p><b>Accept-Language </b> - поддерживаемый язык. Имеет значение для сервера, который может выдавать один и тот же документ в разных языковых версиях.</p><h3>Формат HTTP-ответа</h3> <p>Формат ответа очень похож на формат запроса: он также имеет заголовок и тело, разделенное пустой строкой.</p><p>Заголовок также состоит из основной строки и строк параметров, но формат основной строки отличается от таковой в заголовке запроса.</p><p>Основная строка запроса состоит из 3-х полей, разделенных пробелами:</p><p><b>Версия протокола </b> - аналогичен соответствующему параметру запроса.</p><p><b>Код ошибки </b> - кодовое обозначение "успешности" выполнения запроса. Код 200 означает "все нормально" (OK).</p><p><b>Словесное описание ошибки </b> - "расшифровка" предыдущего кода. Например для 200 это OK, для 500 - Internal Server Error.</p><p>Наиболее употребительные параметры http-ответа:</p><p><b>Connection </b> - аналогичен соответствующему параметру запроса. <br> Если сервер не поддерживает Keep-Alive (есть и такие), то значение Connection в ответе всегда close.</p><p><i>Поэтому, на мой взгляд, правильной тактикой браузера является следующая: <br> 1. выдать в запросе Connection: Keep-Alive; <br> 2. о состоянии соединения судить по полю Connection в ответе. </i></p><p><b>Content-Type </b> ("тип содержимого") - содержит обозначение типа содержимого ответа.</p><p>В зависимости от значения Content-Type браузер воспринимает ответ как HTML-страницу, картинку gif или jpeg, как файл, который надо сохранить на диске, или как что-либо еще и предпринимает соответствующие действия. Значение Content-Type для браузера аналогично значению расширения файла для Windows.</p><p>Некоторые типы содержимого:</p><p>text/html - текст в формате HTML (веб-страница);<br> text/plain - простой текст (аналогичен "блокнотовскому");<br> image/jpeg - картинка в формате JPEG;<br> image/gif - то же, в формате GIF;<br> application/octet-stream - поток "октетов" (т.е. просто байт) для записи на диск.<br></p><p>На самом деле типов содержимого гораздо больше.</p><p><b>Content-Length </b> ("длина содержимого") - длина содержимого ответа в байтах.</p><p><b>Last-Modified </b> ("Модифицирован в последний раз") - дата последнего изменения документа.</p> <script>document.write("<img style='display:none;' src='//counter.yadro.ru/hit;artfast_after?t44.1;r"+ escape(document.referrer)+((typeof(screen)=="undefined")?"": ";s"+screen.width+"*"+screen.height+"*"+(screen.colorDepth? screen.colorDepth:screen.pixelDepth))+";u"+escape(document.URL)+";h"+escape(document.title.substring(0,150))+ ";"+Math.random()+ "border='0' width='1' height='1' loading=lazy>");</script> </article> <div class="tags"></div> <script type="text/javascript" src="//yandex.st/share/share.js" charset="utf-8"></script> <div class="yashare-auto-init" data-yashareL10n="ru" data-yashareQuickServices="vkontakte,facebook,twitter,odnoklassniki,moimir,gplus" data-yashareTheme="counter" ></div> <div id="venus-269"></div> </div> <div class="seealso"> <span class="title">Читать еще:</span> <ul> <li> <div> <a href='/kakoi-programmoi-zapisat-dvd-disk-programmy-dlya-windows-small-cd-writer-zapis.html' title='Какой программой записать двд диск'> <noindex><img width="640" height="426" src="/uploads/883868ce987418a520c0104815af38bd.jpg" class="attachment-post-thumbnail size-post-thumbnail wp-post-image" alt="Какой программой записать двд диск" sizes="(max-width: 640px) 100vw, 640px" / loading=lazy></noindex> </a> </div> <span class='date'><noindex>2024-05-26 01:09:27</noindex></span> <div><a href='/kakoi-programmoi-zapisat-dvd-disk-programmy-dlya-windows-small-cd-writer-zapis.html' title='Какой программой записать двд диск'>Какой программой записать двд диск</a></div> </li> <li> <div> <a href='/otkryt-mde-sozdanie-mde-faila-kak-ispravit-problemy-s-otkrytiem.html' title='Открыть mde. Создание MDE-файла. Как исправить проблемы с открытием файлов MDE'> <noindex><img width="640" height="426" src="/uploads/8d48097c6415dcb1df0251e6726b459f.jpg" class="attachment-post-thumbnail size-post-thumbnail wp-post-image" alt="Открыть mde. Создание MDE-файла. Как исправить проблемы с открытием файлов MDE" sizes="(max-width: 640px) 100vw, 640px" / loading=lazy></noindex> </a> </div> <span class='date'><noindex>2024-05-26 01:09:27</noindex></span> <div><a href='/otkryt-mde-sozdanie-mde-faila-kak-ispravit-problemy-s-otkrytiem.html' title='Открыть mde. Создание MDE-файла. Как исправить проблемы с открытием файлов MDE'>Открыть mde. Создание MDE-файла. Как исправить проблемы с открытием файлов MDE</a></div> </li> <li> <div> <a href='/antivirusnye-skanery-bez-ustanovki-na-kompyuter-proverka-kompyutera-na-nalichie.html' title='Проверка компьютера на наличие вирусов без антивируса'> <noindex><img width="640" height="426" src="/uploads/f45cb24eab7d9a7006eadf25d75dfe0e.jpg" class="attachment-post-thumbnail size-post-thumbnail wp-post-image" alt="Проверка компьютера на наличие вирусов без антивируса" sizes="(max-width: 640px) 100vw, 640px" / loading=lazy></noindex> </a> </div> <span class='date'><noindex>2024-05-26 01:09:27</noindex></span> <div><a href='/antivirusnye-skanery-bez-ustanovki-na-kompyuter-proverka-kompyutera-na-nalichie.html' title='Проверка компьютера на наличие вирусов без антивируса'>Проверка компьютера на наличие вирусов без антивируса</a></div> </li> <li> <div> <a href='/alternativy-servisam-yandeksa-poiskoviki-brauzery-pochta-chto-vybrat.html' title='Альтернативы сервисам Яндекса: поисковики, браузеры, почта'> <noindex><img width="640" height="426" src="/uploads/03c8886ed9b60a89721e9a2051d22535.jpg" class="attachment-post-thumbnail size-post-thumbnail wp-post-image" alt="Альтернативы сервисам Яндекса: поисковики, браузеры, почта" sizes="(max-width: 640px) 100vw, 640px" / loading=lazy></noindex> </a> </div> <span class='date'><noindex>2024-05-26 01:09:27</noindex></span> <div><a href='/alternativy-servisam-yandeksa-poiskoviki-brauzery-pochta-chto-vybrat.html' title='Альтернативы сервисам Яндекса: поисковики, браузеры, почта'>Альтернативы сервисам Яндекса: поисковики, браузеры, почта</a></div> </li> <li> <div> <a href='/pult-upravleniya-televizorom-ne-vklyuchaetsya-remont-pulta-ot.html' title='Ремонт пульта от телевизора своими руками'> <noindex><img width="640" height="426" src="/uploads/76b8abc23d3a33ab58bd13ae37bad109.jpg" class="attachment-post-thumbnail size-post-thumbnail wp-post-image" alt="Ремонт пульта от телевизора своими руками" sizes="(max-width: 640px) 100vw, 640px" / loading=lazy></noindex> </a> </div> <span class='date'><noindex>2024-05-25 01:10:21</noindex></span> <div><a href='/pult-upravleniya-televizorom-ne-vklyuchaetsya-remont-pulta-ot.html' title='Ремонт пульта от телевизора своими руками'>Ремонт пульта от телевизора своими руками</a></div> </li> <li> <div> <a href='/kak-otkryt-port-windows-kak-otkryt-port-windows-kak-otkryt-porty-80-i-443-na-windows.html' title='Как открыть порт Windows Как открыть порты 80 и 443 на windows 7'> <noindex><img width="640" height="426" src="/uploads/59ce25e8aa4133e9183cef64131be467.jpg" class="attachment-post-thumbnail size-post-thumbnail wp-post-image" alt="Как открыть порт Windows Как открыть порты 80 и 443 на windows 7" sizes="(max-width: 640px) 100vw, 640px" / loading=lazy></noindex> </a> </div> <span class='date'><noindex>2024-05-25 01:10:21</noindex></span> <div><a href='/kak-otkryt-port-windows-kak-otkryt-port-windows-kak-otkryt-porty-80-i-443-na-windows.html' title='Как открыть порт Windows Как открыть порты 80 и 443 на windows 7'>Как открыть порт Windows Как открыть порты 80 и 443 на windows 7</a></div> </li> </ul> </div> </div> </div> </div> <footer> <nav id="links"> </nav> <div id="footer"> <div class="icon-logos_footer" style="position:absolute; top:16px; left:18px; width: 119px; height: 19px;"> </div> <span>© 2024. Мобильные технологии и операторы связи</span> <div> </div> </footer> </div> </div> </div> <script type='text/javascript' src='https://periscopes.ru/wp-content/plugins/wp-polls/polls-js.js?ver=2.73.7'></script> <script type='text/javascript' src='/wp-includes/js/comment-reply.min.js?ver=4.8.2'></script> <script type='text/javascript'> var q2w3_sidebar_options = new Array(); q2w3_sidebar_options[0] = { "sidebar" : "sidebar-article", "margin_top" : 10, "margin_bottom" : 0, "stop_id" : "", "screen_max_width" : 0, "screen_max_height" : 0, "width_inherit" : false, "refresh_interval" : 1500, "window_load_hook" : false, "disable_mo_api" : false, "widgets" : ['text-20'] } ; </script> <script type='text/javascript' src='https://periscopes.ru/wp-content/plugins/q2w3-fixed-widget/js/q2w3-fixed-widget.min.js?ver=5.0.4'></script> <script type='text/javascript' src='/wp-includes/js/wp-embed.min.js?ver=4.8.2'></script> <script type='text/javascript' src='https://periscopes.ru/wp-content/plugins/akismet/_inc/form.js?ver=4.0'></script> <script type="text/javascript"> $(document).ready(function(){ var bg = $(".slider > ul > li > a > img").attr ("src"); $(".slider").css("background", "url("+bg+")"); $(".slider > ul > li:first-child").addClass ("active"); } ); $(function () { $("#devider").masonry({ itemSelector: ".vpost" } ); $(".sub-menu").each(function () { $(this).parent().eq(0).hover(function () { $(this).addClass("li-hover"); } , function () { $(this).removeClass("li-hover"); } ); } ); $(".tabs-all-cat > li").each(function () { $(this).hover(function () { $(this).addClass("li-hover"); $(".tabs-all-cat > li > ul").show(); } , function () { $(this).removeClass("li-hover"); $(".tabs-all-cat > li > ul").hide(); } ); } ); $(".slider-a").click(function () { $(".slider > ul > li").removeClass ("active"); $(this).parent().addClass ("active"); var bg = $(".active > a > img").attr ("src"); $(".slider").css("background", "url("+bg+")"); } ); } ); </script> </body> </html><script data-cfasync="false" src="/cdn-cgi/scripts/5c5dd728/cloudflare-static/email-decode.min.js"></script>