HTTP (Hyper Text Transport Protocol) - тот самый язык, на котором "разговаривают" браузеры с веб-серверами, важнейший протокол Интернета...

Типы запросов

Запросы можно разделить на два вида :

GET ;
POST.

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

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

GET используется для чтения сайтов (читаем Интернет);
POST служит для публикации информации на сайтах (пишем Интернет)

URL и параметры запроса

В обоих случаях требуется URL (Uniform Resource Locator) запрашиваемого документа.

URL - это адрес страницы в Интернете. Как правило, он имеет такой вид:
http://<хост>/<путь>
Например :
http://www.example.ru/about.php
Или же такой, если необходимо передать параметры сценарию:
http://<хост>/<путь>?<параметры>
где <параметры> - это набор пар вида:
<имя>=<значение>
разделенных символом & .
Пример:
http://www.example.ru/news.php?id=100&show_comments=yes

У вас может возникнуть вопрос : для чего сценарию передавать параметры ? Динамическая страница (она же сценарий), в отличие от статической, может выдавать различную информацию . Например, сценарий новостной ленты отображает либо список анонсов последних новостей, либо целиком текст конкретной статьи. Что именно хочет увидеть пользователь, сценарий понимает, исходя из переданных ему параметров.

Это могло бы работать следующим образом. Получение списка последних новостей: http://www.example.ru/news.php (URL без параметров). Получение полного текста новостной статьи: http://www.example.ru/news.php?id=1 (URL включает в качестве параметра номер новости).

Обработка параметров URL

А сейчас мы напишем сценарий этой самой новостной ленты. У нее будут два режима :

Всего новостей у нас будет три:

"За качество ответят. Контролировать продукты питания начали по-новому";
"Варшава не раскрывает перечень возможных мер против Минска";
"Павел Астахов намерен добиваться отставки ряда чиновников Удмуртии"

ВНИМАНИЕ! Пример упрощен. Никто никогда не хранит новости в коде сценария. Хранить подобную информацию следует в базе данных. Но это предмет совсем другого урока!

Сейчас же нам важно научиться обрабатывать параметры, переданные через URL. Итак, создайте файл news.php :

"; echo ""; echo "Последние новости"; echo ""; echo ""; echo "

"; echo ""; echo $news[$i]; echo ""; echo "

"; echo ""; echo ""; } // Функция вывода конкретной новости. function show_item($news, $id) { echo ""; echo ""; echo "Новость #$id"; echo ""; echo ""; echo "Вернуться к списку новостей"; echo "

"; echo $news[$id - 1]; echo "

"; echo "

"; echo "Представьте, что здесь много текста и картинок:)"; echo "

"; echo ""; echo ""; } } // Точка входа. // Создаем массив новостей. $news = array(); $news = "За качество ответят. Контролировать продукты питания начали по-новому."; $news = "Варшава не раскрывает перечень возможных мер против Минска"; $news = "Павел Астахов намерен добиваться отставки ряда чиновников Удмуртии"; // Был ли передан id новости в качестве параметра? if (isset($_GET["id"])) { show_item($news, $_GET["id"]); } else { show_list($news); } ?>

Теперь подробно разберем , что же мы написали.

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

Выполнение сценария начинается с того места, где комментарием помечена точка входа . Мы создаем массив, состоящий из трех новостей. Напомним, нумерация элементов в массиве начинается с нуля !

Далее проверяем , был ли передан id новости в качестве параметра. Параметры, переданные через URL, хранятся в системной переменной $_GET. Она представляет собой ассоциативный массив (или, по-другому, словарь).

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

Ключи словаря $_GET - это имена параметров. Функция isset() возвращает true , если переменная определена . Таким образом,
if (isset($_GET["id"]))
следует читать : "если URL запроса содержит параметр id ".

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

Во-первых , может быть не совсем понятно, для чего в одном месте прибавляем к $i единицу, а в другом - вычитаем. Сделано это для того, чтобы пользователь видел URL первой новости так: "news.php?id=1", а не "news.php?id=0". Это хороший тон и не более того.

Во-вторых , обратите внимание на строчку:
echo " Новость #$id ";
Двойные кавычки отличаются от одинарных тем, что если внутри них встречаются имена переменных (со знаком $ ), то они заменяются значениями этих самых переменных. Строка в одинарных кавычках остается как есть без подстановки значений переменных.

В следующем уроке мы разберем как отправить содержимое HTML-Формы, заполненной пользователем, и обработать его.

запроса структура (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-кодированного документа, приложение должно выполнить следующие шаги:

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

Опять же, такие языки, как 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 – метод POST. Метод POST тоже очень часто используется на практике.

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

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

Если пользователь введет в текстовое поле какой-либо текст и нажмет на кнопку «Отправить», то на сервер будет отправлена переменная text со значением того содержимого, которое ввел пользователь. Эта переменная будет отправлена методом POST.

Если в форме написать так:

То данные будут отправляться методом 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.

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

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

Также в этой статье я буду, в основном, ссылаться на стандарт RFC 2616 : Hypertext Transfer Protocol -- HTTP/1.1.

Основы HTTP

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

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

Общение между хостом и клиентом происходит в два этапа: запрос и ответ. Клиент формирует HTTP запрос, в ответ на который сервер даёт ответ (сообщение). Чуть позже, мы более подробно рассмотрим эту схему работы.

Текущая версия протокола HTTP - 1.1, в которой были введены некоторые новые фишки. На мой взгляд, самые важные из них это: поддержка постоянно открытого соединения, новый механизм передачи данных chunked transfer encoding, новые заголовки для кэширования. Что-то из этого мы рассмотрим во второй части данной статьи.

URL

Сердцевиной веб-общения является запрос, который отправляется через Единый указатель ресурсов (URL). Я уверен, что вы уже знаете, что такое URL адрес, однако для полноты картины, решил всё-таки сказать пару слов. Структура URL очень проста и состоит из следующих компонентов:

Протокол может быть как http для обычных соединений, так и https для более безопасного обмена данными. Порт по умолчанию - 80. Далее следует путь к ресурсу на сервере и цепочка параметров.

Методы

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

Существующие методы:

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

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

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

DELETE : служит для удаления существующего ресурса.

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

Также HTTP поддерживает и другие методы:

HEAD : аналогичен GET. Разница в том, что при данном виде запроса не передаётся сообщение. Сервер получает только заголовки. Используется, к примеру, для того чтобы определить, был ли изменён ресурс.

TRACE : во время передачи запрос проходит через множество точек доступа и прокси серверов, каждый из которых вносит свою информацию: IP, DNS. С помощью данного метода, можно увидеть всю промежуточную информацию.

OPTIONS : используется для определения возможностей сервера, его параметров и конфигурации для конкретного ресурса.

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

В ответ на запрос от клиента, сервер отправляет ответ, который содержит, в том числе, и код состояния. Данный код несёт в себе особый смысл для того, чтобы клиент мог отчётливей понять, как интерпретировать ответ:

1xx: Информационные сообщения

Набор этих кодов был введён в HTTP/1.1. Сервер может отправить запрос вида: Expect: 100-continue, что означает, что клиент ещё отправляет оставшуюся часть запроса. Клиенты, работающие с HTTP/1.0 игнорируют данные заголовки.

2xx: Сообщения об успехе

Если клиент получил код из серии 2xx, то запрос ушёл успешно. Самый распространённый вариант - это 200 OK. При GET запросе, сервер отправляет ответ в теле сообщения. Также существуют и другие возможные ответы:

202 Accepted : запрос принят, но может не содержать ресурс в ответе. Это полезно для асинхронных запросов на стороне сервера. Сервер определяет, отправить ресурс или нет.
204 No Content : в теле ответа нет сообщения.
205 Reset Content : указание серверу о сбросе представления документа.
206 Partial Content : ответ содержит только часть контента. В дополнительных заголовках определяется общая длина контента и другая инфа.

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

Своеобразное сообщение клиенту о необходимости совершить ещё одно действие. Самый распространённый вариант применения: перенаправить клиент на другой адрес.

301 Moved Permanently : ресурс теперь можно найти по другому URL адресу.
303 See Other : ресурс временно можно найти по другому URL адресу. Заголовок Location содержит временный URL.
304 Not Modified : сервер определяет, что ресурс не был изменён и клиенту нужно задействовать закэшированную версию ответа. Для проверки идентичности информации используется ETag (хэш Сущности - Enttity Tag);

4xx: Клиентские ошибки

Данный класс сообщений используется сервером, если он решил, что запрос был отправлен с ошибкой. Наиболее распространённый код: 404 Not Found. Это означает, что ресурс не найден на сервере. Другие возможные коды:

400 Bad Request : вопрос был сформирован неверно.
401 Unauthorized : для совершения запроса нужна аутентификация. Информация передаётся через заголовок Authorization.
403 Forbidden : сервер не открыл доступ к ресурсу.
405 Method Not Allowed : неверный HTTP метод был задействован для того, чтобы получить доступ к ресурсу.
409 Conflict : сервер не может до конца обработать запрос, т.к. пытается изменить более новую версию ресурса. Это часто происходит при PUT запросах.

5xx: Ошибки сервера

Ряд кодов, которые используются для определения ошибки сервера при обработке запроса. Самый распространённый: 500 Internal Server Error. Другие варианты:

501 Not Implemented : сервер не поддерживает запрашиваемую функциональность.
503 Service Unavailable : это может случиться, если на сервере произошла ошибка или он перегружен. Обычно в этом случае, сервер не отвечает, а время, данное на ответ, истекает.

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

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

Давайте посмотрим на структуру передаваемого сообщения через HTTP:

Message = *() CRLF [] = Request-Line | Status-Line = Field-Name ":" Field-Value

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

Тело ответа может содержать полную информацию или её часть, если активирована соответствующая возможность (Transfer-Encoding: chunked). HTTP/1.1 также поддерживает заголовок Transfer-Encoding.

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

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

Что-то мы уже рассмотрели в этой статье, что-то подробней затронем во второй части.

Заголовок via используется в запросе типа TRACE, и обновляется всеми прокси-серверами.

Заголовок Pragma используется для перечисления собственных заголовков. К примеру, Pragma: no-cache - это то же самое, что Cache-Control: no-cache. Подробнее об этом поговорим во второй части.

Заголовок Date используется для хранения даты и времени запроса/ответа.

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

Transfer-Encoding предназначается для разделения ответа на несколько фрагментов с помощью Transfer-Encoding: chunked. Это нововведение версии HTTP/1.1.

Заголовки сущностей

В заголовках сущностей передаётся мета-информация контента:

Все заголовки с префиксом Content- предоставляют информацию о структуре, кодировке и размере тела сообщения.

Заголовок Expires содержит время и дату истечения сущности. Значение “never expires” означает время + 1 код с текущего момента. Last-Modified содержит время и дату последнего изменения сущности.

С помощью данных заголовков, можно задать нужную для ваших задач информацию.

Формат запроса

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

SP - это разделитель между токенами. Версия HTTP указывается в HTTP-Version. Реальный запрос выглядит так:

GET /articles/http-basics HTTP/1.1 Host: www.articles.com Connection: keep-alive Cache-Control: no-cache Pragma: no-cache Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Список возможных заголовков запроса:

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

Формат ответа

Формат ответа отличается только статусом и рядом заголовков. Статус выглядит так:

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

HTTP версия
Код статуса
Сообщение статуса, понятное для человека

Обычный статус выглядит примерно так:

HTTP/1.1 200 OK

Заголовки ответа могут быть следующими:

Age время в секундах, когда сообщение было создано на сервере.
ETag MD5 сущности для проверки изменений и модификаций ответа.
Location используется для перенаправления и содержит новый URL адрес.
Server определяет сервер, где было сформирован ответ.

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

Инструменты для определения HTTP трафика

Существует множество инструментов для мониторинга HTTP трафика. Вот несколько из них:

Наиболее часто используемый - это Chrome Developers Tools:

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

Для отслеживания HTTP трафика вам потребуется curl, tcpdump и tshark.

Библиотеки для работы с HTTP - jQuery AJAX

Поскольку jQuery очень популярен, в нём также есть инструментарий для обработки HTTP ответов при AJAX запросах. Информацию о jQuery.ajax(settings) можете найти на официальном сайте .

Передав объект настроек (settings), а также воспользовавшись функцией обратного вызова beforeSend, мы можем задать заголовки запроса, с помощью метода setRequestHeader().

$.ajax({ url: "http://www.articles.com/latest", type: "GET", beforeSend: function (jqXHR) { jqXHR.setRequestHeader("Accepts-Language", "en-US,en"); } });

Если хотите обработать статус запроса, то это можно сделать так:

$.ajax({ statusCode: { 404: function() { alert("page not found"); } } });

Итог

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