Запрос и заголовки

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

Далее идут заголовки, из коих следует выделить два:

Cookie - передаем серверу все, что у нас для этого сервера хранится. Что он будет с этим делать, его проблемы. Важное замечание, у нас локально хранится море разного мусора для разных серверов. Отсылаем мы только то, что касается ЭТОГО сервера, который сейчас опрашиваем. Именно поэтому каванга не получит адриверовской куки.

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

Примеры:

GET /exp?sid=5&bt=5&ct=2&bc=3 HTTP/1.1

Host: b.kavanga.ru

Cookie: kui1v=1234567

Referrer: https://www.neuro.neva.ru

POST /exp HTTP/1.1

Host: b.kavanga.ru

Cookie: kui1v=1234567

Referrer: https://www.neuro.neva.ru

sid=5&bt=5&ct=2&bc=3

Постарался показать разницу между протоколами. Заморока в адресе страницы. При нормальном запросе все параметры в адресной строке. При POST запросе, параметры скрыты. На страницу, полученную пост-запросом нельзя (бестолку) ставить ГА, невозможно определить по адресу, что это за страница, в том числе нельзя отличить первую страницу от последней. Каванга, как и все остальные крутилки, с постом не работает. Передавать на сторону клиента параметры из баннера можно, но только методом GET. Есть и хорошие новости - точка входа кампании (Landing Page) никогда не делается этим нехорошим методом. Просто надо знать, что если клиент с честными глазами утверждает, что пост - это круто и секурно, и просит сделать ему баннер, из которого можно сразу расплатиться кредиткой... я не возьмусь решать эту задачу. Потому и не делается...

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

По большому счету бывает всего 4 разновидности ответа

- “ок” все хорошо, вот ваш ответ (200+). Есть разновидность “нет ответа” 204

- “редирект” идите ка вы за своим контентом во-от туда (300+)

- “малый ахтунг” сервер не знает, что ответить, но вроде бы все в порядке (400+)

- “великий ахтунг” серверу хана (500+)

Обычно мы отвечаем 200 при показе баннера, 204 на запрос зеропикселя, 304 на клик. 404 выдает сервер, если посетитель хочет странного. Крайне редкая ситуация. Ну, когда падаем, выдается 500. В интерфейсе все видели)

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

X-kbe-place-id:

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

X-kbe-flight-id:

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

DNS

Динамический сервер имен. Ну... вобщем, без него интернет не работает:) По сути что мы должны понимать - загрузка какого то URL происходит в несколько этапов, сначала опрашивается этот самый сервер имен, добывается оттуда уже номер компьютера в сети по доменному имени. Ну как в карту посмотреть, когда идем куда то по адресу. Затем отправляется уже запрос тому компьютеру и начинаем с ним общаться. А номер на некоторое время запоминаем. Через несколько минут опять забываем. Разумеется, опрос DNS занимает некоторое время. Поэтому, например, ГА считает переходы медленнее, чем сама каванга. Потому что на сайте клиета посетитель должен загрузить как бы два зеропикселя - и с каванги и с гугла. За адресом гугла ему надо обратиться к DNS, а адрес каванги он помнит, потому что только что на кавангу кликал. Пусть это секунда, но гугл сработает медленнее.