Перехват сетевых запросов

Сетевые события — события вкладки, поэтому их ловит chromedp.ListenTarget: подписка принимает контекст и функцию, которой протокол отдаёт каждое событие. Внутри — классический type switch: network.EventRequestWillBeSent приходит в момент отправки и несёт RequestID, адрес, метод и тип ресурса ev.Type, где ResourceTypeXHR отличает AJAX от документов и скриптов; network.EventResponseReceived приходит с ответом и несёт статус, MIME-тип и заголовки в ev.Response. Поле ev.Type бывает Document, Script, Image, Stylesheet, Fetch — по нему отделяют API-запросы от остального потока. Включать домен руками не нужно: Run сам вызывает network.Enable при старте, поток событий идёт сразу. Колбэк выполняется синхронно в потоке обработки событий, поэтому блокировать в нём нельзя: действие запускается отдельной goroutine, иначе получите дедлок — об этом отдельный разговор ниже. Не путайте парную ListenBrowser: она ловит только браузерные события вроде появления новых целей, и target-события, включая сеть, к ней не приходят. Подписка отменяется вместе с контекстом: в цикле обхода, где контекст пересоздаётся на страницу, слушатель живёт ровно одну страницу.

Поток событий сети упорядочен, и порядок стоит выучить заранее. На каждый запрос приходят EventRequestWillBeSent — заявка с адресом и типом; затем EventResponseReceived — заголовки и статус; затем EventLoadingFinished — сигнал, что браузер получил тело целиком. Сбой вместо финиша — EventLoadingFailed с ErrorText и флагом Canceled: запрос не доехал, и ждать для него тело бессмысленно. Запрос и ответ связываются RequestID: держите карту, где ID — ключ, а значение — адрес и тип, и таймлайн каждого запроса соберётся в одну строку. Пара практических следствий. Первое: фильтруйте рано — условие по домену и типу прямо в колбэке дешевле, чем потом разгребать срез из сотни адресов. Второе: события приходят и на навигацию самого документа — Document-запросы попадают в тот же поток, поэтому ResourceTypeXHR — не украшение, а способ не смешивать страницу и её API.

Собрать адреса — половина дела; главный приз — тело XHR-ответа с данными. Механика двухшаговая: в колбэке запоминаете RequestID интересного ответа — например, по суффиксу адреса и MIME-типу application/json, — а после Run вызываете network.GetResponseBody(id).Do(ctx): действие возвращает тело и флаг base64, потому что бинарные ответы протокол отдаёт закодированными. После Run вызов безопасен: поток событий отработал, дедлока нет. Флаг base64 — не экзотика: протокол им отвечает и на бинарные, а иногда и на большие текстовые ответы, поэтому проверять его нужно всегда. Для главного документа есть готовое действие chromedp.RunResponse: оно вернёт *network.Response страницы, на которую приехала навигация, со статусом и адресом — без ручного перехвата. Кейс собран из этих частей: страница-отчёт грузит таблицу запросом к /api/quotes, селектор WaitVisible убеждается, что данные приехали, GetResponseBody отдаёт исходный JSON, и json.Unmarshal разбирает его в структуру — минуя весь слой разметки. Кейс честно двухслойный: слушатель — для адресов и ID, а чтение тела — обычное действие после Run. Разделение выглядит дольше, чем «всё в одном колбэке», но именно оно делает перехват стабильным: слушатель не блокируется, а данные достаются в удобном месте с нормальными проверками ошибок.

Перехват умеет не только слушать — тот же протокол позволяет и запрещать. За это отвечает Fetch-домен: fetch.Enable с паттернами объявляет перехват по шаблону адреса и стадии запроса, на каждый подходящий запрос приходит событие RequestPaused, а решение принимается командой FailRequest — отменить — или ContinueRequest — пропустить. Классическое применение: отсечь трекеры и рекламные домены по URL-паттерну ещё до отправки, и страница грузится быстрее и дешевле — экономия трафика на картинки, аналитику и шрифты достигает десятков процентов. Подробный разбор с примерами — отдельная тема восемнадцатого урока про блокировку картинок и шрифтов. Паттерны — это строки в духе ://tracker.example/: чем уже шаблон, тем меньше событий перехвата и выше скорость, а слишком широкие шаблоны режут и нужные запросы. Здесь важна одна оговорка: Fetch-домен появился в протоколе не с рождения, и на старых версиях браузера паттерны просто не отработают — механизм зависит от версии протокола DevTools, о чём честно говорит таблица ниже. Тонкость стадий: перехват можно ставить на запрос — тогда решение принимается до отправки, — и на ответ — тогда можно переписать заголовки. Для трекеров нужна ранняя стадия: зачем загружать то, что вы всё равно отмените.

События сети честны, как протокол, и имеют те же границы. Первое — версии: cdproto повторяет протокол DevTools, протокол меняется вместе с Chrome, и механизм, работающий на свежем браузере, может отсутствовать или отличаться на старом; Fetch-домен — свежий случай, базовые network-события — старые и стабильные. Второе — полнота: поток событий отражает взгляд браузера, редиректы переписывают RequestID, кэш может схлопнуть запрос до одного события, service worker перехватывает часть трафика по своим правилам — точный подсчёт всех сетевых операций протокол не обещает. Третье — дисциплина потоков: колбэк синхронный и короткий, вся тяжёлая работа — после Run или в своей goroutine. Проверяйте перехват на той версии браузера, с которой пойдёт в бой: локальный прогон на установленном Chrome даёт правду, а отчёт о событиях полезно писать в лог — расхождение с ожиданием видно сразу. Отсюда и тестирование: прогон на той же версии Chrome, что в продакшене, снимает большинство сюрпризов заранее. И ещё одна граница — права: перехватывает не chromedp, а браузер; библиотека лишь передаёт команды протокола, и всё, чего нет в протоколе, не появится от усилий на стороне Go.