Рассмотрим этот HTML-код:

Введите текст:

То данные будут отправляться методом GET.

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

Еще одно отличие метода POST от GET, метод POST скрывает все передаваемые им переменные и их значения, в своём теле (Entity-Body). В случае с методом GET они хранились в строке запроса (Request-URI).

Вот пример запроса, выполненного методом POST:

POST / HTTP/1.0\r\n
Host: www.site.ru\r\n
Referer: http://www.site.ru/index.html\r\n
Cookie: income=1\r\n
Content-Type: application/x-www-form-urlencoded\r\n
Content-Length: 35\r\n
\r\n
login=Dima&password=12345

Таким образом, передавая данные методом POST, их будет намного труднее перехватить злоумышленнику, т.к. они скрыты от непосредственного просмотра, поэтому метод передачи данных методом POST считается более безопасным способом.

Кроме того, методом POST можно передавать не только текст, но и мультимедиа данные (картинки, аудио, видео). Существует специальный параметр Content-Type, который определяет тот вид информации, который необходимо передать.

Ну и, наконец, чтобы на сервере получить данные, которые были переданы этим методом, используется переменная POST.

Вот пример обработки на языке PHP:

echo $_POST[‘text’];
?>

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

Давайте более подробно рассмотрим эту структуру, по которой строятся запросы и ответы в протоколе HTTP.

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

Пустая строка (разделитель)

Post и Get запросы, какая между ними разница и что лучше и для каких целей?

тело сообщения (Entity Body) – необязательный параметр

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

Заголовки – описывают тело сообщений, передают различные параметры и др. сведения и информацию.

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

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

Более подробно, каждый элемент запроса, мы рассмотрим в следующих заметках.

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

Запрос от браузера:

Host: webgyry.info

Cookie: wp-settings

Connection: keep-alive

В следующем примере уже присутствует тело сообщения.

Ответ сервера:

Content-Type: text/html; charset=UTF-8

Transfer-Encoding: chunked

Connection: keep-alive

Keep-Alive: timeout=5

X-Pingback: //webgyry.info/xmlrpc.php

Вот такими сообщениями обмениваются клиент и сервер по протоколу HTTP.

Кстати, хотите узнать есть ли смысл в каком-то элементе на вашем сайте с помощью «целей» Яндекс Метрики и Google Analytics?

Уберите то, что НЕ работает, добавьте то, что работает и удвойте вашу выручку.

Курс по настройке целей Яндекс Метрики..

Курс по настройке целей Google Analytics..

HTTP клиент посылает запрос на сервер в форме cсообщения-запроса, которое имеет следующий формат:

• Строка запроса (обязательный элемент)
• Заголовок (опционалный элемент)
• Пустая строка (обязательный элемент)
• Тело сообщения (опциональный элемент)

Рассмотрим каждый из этих элементов по отдельности.

Строка запроса

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

Расмотрим данный элемент более подробно

Метод запроса

Данный элемент указывает метод, который должен быть вызван на стороне сервера по указанному индентификатору URI.

В HTTP существует восемь методов:

• HEAD
  Используется для получения строки статуса и заголовка от сервера по URI. Не изменяет данные.
• GET
  Используется для получения данных от сервера по указанному URI. Не изменяет данные.
• POST
  Используется для отправки данных на сервер (например информации о разработчике и т.д.) с помощью форм HTML.
• PUT
  Замещает все предыдущие данные на ресурсе новыми загруженными данными.
• DELETE
  Удаляет все текущие данные на ресурсе, определённом URI.
• CONNECT
  Устанавливает туннельное соединение с сервером по указанному URI.
• OPTIONS
  Описывает свойства соединения для указанного ресурса.
• TRACE
  Предоставляет сообщение, содержащее обратный трейс расположения указанного в URI ресурса.

URI запроса

URI (Uniform Resource Identifier) – это идентификатор ресурса на который отправляется запрос. Ниже приведён наиболее часто встречающийся формат URI:

‘*’ используется когда HTTP запрос не относится к конкретному ресурсу, но к серверу. Используется только в случае, когда метод не обязательно применять к ресурсу. Например,

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

асболютный_путь | источник используется наиболее чатсо.

Учимся работать с GET и POST запросами

Запрашивается конкретный ресурс определённого сервера. Например, клиент хочет получить ресурс с сервера через 80-й порт. Адрес ресурса “www.proselyte.net” и отправляет следующий запрос:

Запрос полей заголовка

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

Ниже приведён списко наиболее важных полей заголовка, которые могут быть использованы:

• Accept-Charset
• Accept-Encoding
• Accept-Language
• Authorization
• Expect
• If-Match
• If-Modified-Since
• If-None-Match
• If-Range
• If-Unmodified-Since
• Range
• Referer
• User-Agent

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

Пример HTTP запроса

На этом мы заканчиваем изучение запросов HTTP.
В следующей статье мы рассмотрим HTTP ответы.

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

Самый простой способ, как можно создать запрос методом GET- это набрать URL-адрес в адресную строку браузера.

Браузер передаст серверу примерно следующую информацию:

GET / HTTP/1.1
Host: webgyry.info
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101 Firefox/18.0
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
Cookie: wp-settings
Connection: keep-alive

Запрос состоит из двух частей:

1. строка запроса (Request Line)

2. заголовки (Message Headers)

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

Различие между методами GET и POST

Это можно делать с помощью специальных GET параметров.

Чтобы добавить GET параметры к запросу, нужно в конце URL-адреса поставить знак «?» и после него начинать задавать их по следующему правилу:

имя_параметра1=значение_параметра1& имя_параметра2=значение_параметра2&…

Разделителем между параметрами служит знак «&».

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

http://site.ru/page.php?name=dima&age=27

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

Вот пример, как это можно сделать на PHP.

echo «Ваше имя: » . $_GET[«name»] . «
»;
echo «Ваш возраст: » . $_GET[«age»] . «
»;
?>

Конструкция $_GET[«имя_параметра»] позволяет выводить значение переданного параметра.

В результате выполнения этого кода в браузере выведется:

Ваше имя: dima
Ваш возраст: 27

мы тоже выполняем запрос к серверу методом GET.

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

Если, для того, чтобы обратиться к серверу методом GET, нам достаточно было набрать запрос в URL-адрес, то в методе POST все работает по другому принципу.

Для того, чтобы выполнить этот вид запроса, нам необходимо нажать на кнопку с атрибутом type=»submit», которая расположена на веб-странице. Обратите внимание, что эта кнопка расположена в элементе , у которого установлен атрибут method со значением post.

Рассмотрим этот HTML-код:

Введите текст:

То данные будут отправляться методом GET.

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

Еще одно отличие метода POST от GET, метод POST скрывает все передаваемые им переменные и их значения, в своём теле (Entity-Body). В случае с методом GET они хранились в строке запроса (Request-URI).

Вот пример запроса, выполненного методом POST:

POST / HTTP/1.0\r\n
Host: www.site.ru\r\n
Referer: http://www.site.ru/index.html\r\n
Cookie: income=1\r\n
Content-Type: application/x-www-form-urlencoded\r\n
Content-Length: 35\r\n
\r\n
login=Dima&password=12345

Таким образом, передавая данные методом POST, их будет намного труднее перехватить злоумышленнику, т.к. они скрыты от непосредственного просмотра, поэтому метод передачи данных методом POST считается более безопасным способом.

Кроме того, методом POST можно передавать не только текст, но и мультимедиа данные (картинки, аудио, видео). Существует специальный параметр Content-Type, который определяет тот вид информации, который необходимо передать.

Ну и, наконец, чтобы на сервере получить данные, которые были переданы этим методом, используется переменная POST.

Вот пример обработки на языке PHP:

echo $_POST[‘text’];
?>

Кстати, я настраиваю отчеты, цели и события в системах Яндекс Метрика и Google Analytics.

запроса структура (8)

В запросе HTTP GET параметры отправляются как строка запроса :

Http://example.com/page?parameter=value&also=another

В запросе HTTP POST параметры не отправляются вместе с URI.

Где значения? В заголовке запроса? В теле запроса? На что это похоже?

Answers

Значения форм в HTTP-POST-сообщениях отправляются в тело запроса в том же формате, что и запрос.

Для получения дополнительной информации см. spec .

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

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

POST /?AuthId=YOURKEY&Action=WebServiceAction&Signature=rcLXfkPldrYm04 HTTP/1.1 Content-Type: text/tab-separated-values; charset=iso-8859-1 Content-Length: Host: webservices.domain.com Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: identity User-Agent: Mozilla/3.0 (compatible; Indy Library) name id John G12N Sarah J87M Bob N33Y

Этот подход логически объединяет QueryString и Body-Post с использованием одного Content-Type который является «инструкцией по синтаксическому разбору» для веб-сервера.

Обратите внимание: HTTP / 1.1 завернута в #32 (пробел) слева и с #10 (Line feed) справа.

Прежде всего, давайте GET и POST

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

это формат

GET /someweb.asp?data=value HTTP/1.0

здесь data=value - переданное значение строки запроса.

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

POST /somweb.aspHTTP/1.0 Host: localhost Content-Type: application/x-www-form-urlencoded //you can put any format here Content-Length: 11 //it depends Name= somename

Почему POST над GET?

В GET значение, отправляемое на серверы, обычно добавляется к базовому URL-адресу в строке запроса. Это позволяет взломать ваши данные (это было проблемой в дни для Facebook, где были установлены ваши учетные данные), поэтому POST используемый для отправки данных на сервер, который использовал Request Body для отправки ваших данных на сервер, который более безопасен, поскольку он скрывает ваши данные, и он получает ваши данные из полей, вычисляет их длину и добавляет их в header для content-length и никакие важные данные напрямую не добавляются к URL

теперь, когда ваш запрос защищен, любые значения, отправляемые на сервер, могут быть отправлены в Request Body поскольку имя подразумевает, что оно будет содержать пользователей данных, которые хотели бы отправить (и Он отправляется в URL Encoded формате URL Encoded), а Request Headers будут сохраняйте запрос безопасным путем сравнения значений в Request Body с Request Headers

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

и вы всегда можете добавить больше значений в Request Headers такие как Cache-Control , Origin , Accept .

Короткий ответ: в POST-запросах значения отправляются в «тело» запроса. В веб-формах они, скорее всего, отправляются с медиа-типом application/x-www-form-urlencoded или multipart/form-data . Языки программирования или фреймворки, предназначенные для обработки веб-запросов, обычно выполняют «The Right Thing ™» с такими запросами и обеспечивают вам легкий доступ к легко декодированным значениям (например, $_REQUEST или $_POST в PHP или cgi.FieldStorage() , flask.request.form в Python).

Теперь давайте немного отвлечемся, что может помочь понять разницу;)

Разница между запросами GET и POST в значительной степени семантична. Они также «используются» по-разному, что объясняет разницу в том, как передаются значения.

GET (соответствующий раздел RFC)

При выполнении запроса GET вы запрашиваете сервер для одного или набор объектов. Чтобы клиент мог фильтровать результат, он может использовать так называемую «строку запроса» URL-адреса. Строка запроса является частью после? , Это часть синтаксиса URI .

Итак, с точки зрения вашего кода приложения (часть, которая получает запрос) вам нужно будет проверить часть запроса URI, чтобы получить доступ к этим значениям.

Обратите внимание, что ключи и значения являются частью URI. Браузеры могут налагать ограничение на длину URI. В стандарте HTTP указано, что ограничений нет. Но на момент написания этой статьи большинство браузеров ограничивают URI (у меня нет конкретных значений). Запросы GET никогда не должны использоваться для отправки новой информации на сервер. Особенно не крупные документы. Здесь вы должны использовать POST или PUT .

POST (соответствующий раздел RFC)

При выполнении запроса POST клиент фактически отправляет новый документ удаленному хосту. Таким образом, строка запроса не (семантически) имеет смысл. Вот почему у вас нет доступа к ним в вашем коде приложения.

POST немного сложнее (и более гибким):

При получении запроса POST вы всегда должны ожидать «полезную нагрузку», или в терминах HTTP: тело сообщения . Тело сообщения само по себе довольно бесполезно, поскольку нет стандартного (насколько я могу судить. Может быть, application / octet-stream?) Формата. Формат тела определяется заголовком Content-Type . При использовании элемента HTML FORM с method="POST" это обычно application/x-www-form-urlencoded . Другим очень распространенным типом является multipart/form-data если вы используете загрузку файлов. Но может быть что угодно : от text/plain , над application/json или даже с настраиваемым application/octet-stream .

В любом случае, если запрос POST выполняется с Content-Type который не может быть обработан приложением, он должен вернуть код состояния 415 .

Большинство языков программирования (и / или веб-фреймворки) предлагают способ де-кодирования тела сообщения от / до наиболее распространенных типов (например, application/x-www-form-urlencoded , multipart/form-data или application/json) , Так что это легко. Пользовательские типы требуют потенциально немного больше работы.

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

1. Прочитайте поле Content-Type
2. Если значение не является одним из поддерживаемых типов носителей, тогда возвращайте ответ с кодом статуса 415
3. в противном случае, декодировать значения из тела сообщения.

Опять же, такие языки, как PHP, или веб-фреймворки для других популярных языков, вероятно, справятся с этим для вас. Исключением является ошибка 415 . Никакая структура не может предсказать, какие типы контента ваше приложение выбирает для поддержки и / или не поддержки. Это зависит от вас.

PUT (соответствующий раздел RFC)

Запрос PUT обрабатывается точно так же, как запрос POST . Большая разница заключается в том, что запрос POST должен позволить серверу решить, как (и если вообще) создать новый ресурс. Исторически (из теперь устаревшего RFC2616 он должен был создать новый ресурс как «подчиненный» (дочерний) URI, куда был отправлен запрос).

Предполагается, что запрос PUT должен «откладывать» ресурс именно в этом URI и именно с этим контентом. Не больше, не меньше. Идея заключается в том, что клиент несет ответственность за создание полного ресурса до «PUTting». Сервер должен принять его как есть на данном URL-адресе.

Как следствие, запрос POST обычно не используется для замены существующего ресурса. Запрос PUT может создавать и заменять.

Примечание

Существуют также « параметры пути », которые могут использоваться для отправки дополнительных данных на пульт, но они настолько необычны, что я не буду вдаваться в подробности. Но, для справки, вот отрывок из RFC:

Помимо точечных сегментов в иерархических путях, сегмент пути считается непрозрачным по обобщенному синтаксису. В URI, создающих приложения, часто используются зарезервированные символы, разрешенные в сегменте, для разграничения подкомпонентов, специфичных для конкретной схемы или разнесения. Например, зарезервированные символы с запятой (";") и равно ("=") часто используются для разграничения параметров и значений параметров, применимых к этому сегменту. Зарезервированный символ запятой (",") часто используется для аналогичных целей. Например, один производитель URI может использовать сегмент, такой как «name; v = 1.1», чтобы указать ссылку на версию 1.1 «name», тогда как другой может использовать сегмент, такой как «name, 1.1», чтобы указать его. Типы параметров могут быть определены с помощью специфичной для схемы семантики, но в большинстве случаев синтаксис параметра специфичен для реализации алгоритма разыменования URI.

Вы не можете вводить его непосредственно в строке URL браузера.

Вы можете увидеть, как данные POST отправляются в Интернете с помощью HTTP-заголовков, например. Результат будет примерно таким

Http://127.0.0.1/pass.php POST /pass.php HTTP/1.1 Host: 127.0.0.1 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate DNT: 1 Referer: http://127.0.0.1/pass.php Cookie: passx=87e8af376bc9d9bfec2c7c0193e6af70; PHPSESSID=l9hk7mfh0ppqecg8gialak6gt5 Connection: keep-alive Content-Type: application/x-www-form-urlencoded Content-Length: 30 username=zurfyx&pass=password

Где он говорит

Content-Length: 30 username=zurfyx&pass=password

будут значения post.

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

Обычно тип содержимого - application/x-www-form-urlencoded , поэтому тело запроса использует тот же формат, что и строка запроса:

Parameter=value&also=another

Когда вы используете загрузку файла в форме, вместо этого вы используете кодировку multipart/form-data , которая имеет другой формат. Это сложнее, но вам обычно не нужно заботиться о том, как это выглядит, поэтому я не буду показывать пример, но может быть полезно знать, что он существует.

Тип носителя по умолчанию в POST-запросе - application/x-www-form-urlencoded . Это формат для кодирования пар ключ-значение. Ключи могут быть дублированы. Каждая пара ключ-значение разделяется символом & , и каждый ключ отделяется от его значения символом = .

Например:

Name: John Smith Grade: 19

Записывается как:

Name=John+Smith&Grade=19

Он помещается в тело запроса после заголовков HTTP.

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

Обоснование:
Речь идет о соглашениях между разработчиками для пользовательских заголовков конкретных приложений - « данных, имеющих отношение к их учетной записи » - которые не имеют ничего общего с поставщиками, органами стандартов или протоколами, которые должны быть реализованы третьими сторонами, за исключением того, что разработчик, о котором идет речь просто нужно избегать заголовков, которые могут иметь другое предназначение для использования серверами, прокси или клиентами. По этой причине приведенные примеры «X-Gzip / Gzip» и «X-Forwarded-For / Forwarded-For» являются спорными. Возникает вопрос о соглашениях в контексте частного API, аналогичных соглашениям об именах параметров URL-запроса. Это вопрос предпочтения и расстояния между именами; опасения по поводу «X-ClientDataFoo», поддерживаемые любым прокси-сервером или поставщиком без «X», явно неуместны.

В префиксе «X-» нет ничего особенного или волшебного, но это помогает понять, что это настраиваемый заголовок. На самом деле, RFC-6648 и др. Помогают предотвратить использование префикса «X-», поскольку - поскольку поставщики HTTP-клиентов и серверов отказываются от префикса - ваши приложения, частные API-интерфейсы, персональные данные, механизм передачи становится еще лучше изолированным от коллизий между именами и небольшим количеством официальных зарезервированных заголовков. Тем не менее, мои личные предпочтения и рекомендации - сделать еще один шаг и сделать, например, «X-ACME-ClientDataFoo» (если ваша компания-виджет «ACME»).

IMHO спецификация IETF недостаточно специфична для ответа на вопрос OP, поскольку он не может отличить совершенно разные варианты использования: (A) поставщики, внедряющие новые глобально применимые функции, такие как «Forwarded-For», с одной стороны, vs. (B) разработчики приложений передают строки, зависящие от приложения, к клиенту и серверу. Спектр касается только первого, (A). Вопрос здесь в том, существуют ли соглашения для (B). Есть. Они включают группирование параметров в алфавитном порядке и разделение их от многих соответствующих стандартам заголовков типа (A). Использование префикса «X-» или «X-ACME-» является удобным и законным для (B) и не противоречит (A). Чем больше продавцов перестанут использовать «X-» для (A), тем станут более четкими (B).

Пример:
Google (которые несут немного веса в различных органах стандартизации) - на сегодняшний день, 20141102 в этом незначительном изменении моего ответа - в настоящее время используется «X-Mod-Pagespeed», чтобы указать версию своего модуля Apache, участвующего в преобразуя данный ответ. Кто-нибудь действительно предлагает, чтобы Google использовал «Mod-Pagespeed» без «X-» и / или попросил IETF благословить его использование?

Резюме:
Если вы используете пользовательские заголовки HTTP (как иногда подходящую альтернативу куки-файлам) в своем приложении для передачи данных на ваш сервер, и эти заголовки явно не предназначены для использования вне контекста вашего приложения, сопоставление имен с префиксом «X-» или «X-FOO-» является разумным и общепринятым.

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

Давайте более подробно рассмотрим эту структуру, по которой строятся запросы и ответы в протоколе HTTP.

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

1. строка запроса (Request Line)

2. заголовки (Message Headers)

Пустая строка (разделитель)

3. тело сообщения (Entity Body) – необязательный параметр

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

Заголовки – описывают тело сообщений, передают различные параметры и др. сведения и информацию.

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

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

Более подробно, каждый элемент запроса, мы рассмотрим в следующих заметках.

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

Запрос от браузера:

GET / HTTP/1.1

Host: сайт

User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101 Firefox/18.0

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

Cookie: wp-settings

Connection: keep-alive

В следующем примере уже присутствует тело сообщения.

Ответ сервера:

HTTP/1.1 200 OK

Content-Type: text/html; charset=UTF-8

Transfer-Encoding: chunked

Connection: keep-alive

Keep-Alive: timeout=5

Server: Apache

X-Pingback: //сайт/xmlrpc.php

Вот такими сообщениями обмениваются клиент и сервер по протоколу HTTP.

Кстати, я настраиваю отчеты, цели и события в системах Яндекс Метрика и Google Analytics.

Вашему вниманию предлагается описание основных аспектов протокола 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://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 составляется по следующей схеме:

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

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

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

Теги: Добавить метки