Цепочки редиректов ломают скрейперы. Бинарные ответы повреждаются при декодировании в текст. Две проблемы, которые постоянно возникают, как только вы проходите стадию «запросить страницу, распарсить HTML».
Мы выпустили две новые опции запросов для решения обеих проблем: followRedirects и returnBuffer. Они уже доступны в API.
Как это работает
Управление редиректами с followRedirects
Большинство API для скрейпинга обрабатывают редиректы как булево значение: следовать за ними или нет. Это работает, пока вы не столкнетесь с зацикленной цепочкой редиректов, или пока вам не понадобится сам промежуточный ответ 302, чтобы извлечь параметр отслеживания.
В FourA параметр followRedirects принимает целое число от 0 до 20. Опустите его (или установите в 0), и вы получите сырой ответ редиректа обратно, со всеми заголовками. Установите его в 5, и запрос пройдет до пяти прыжков, прежде чем вернуть то, на чем он остановится.
curl -X POST "https://eu.api.foura.ai/v1/request" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"url": "https://example.com/short-link",
"followRedirects": 3,
"unblocker": true
}'
Это позволяет пройти до трех редиректов. Если цепочка разрешится за два, вы получите финальную страницу. Если она длиннее трех, вы получите то, что вернул третий прыжок.
Разница имеет большее значение, чем вы думаете. Сайты e-commerce перенаправляют через URL-адреса отслеживания, прежде чем попасть на страницу продукта. Вы хотите следовать по ним. Но партнерские сети и сокращатели ссылок иногда создают цепочки, которые уходят вглубь на шесть, семь, восемь прыжков. А некоторые циклы редиректов вообще никогда не разрешаются. Ограничение конкретным числом означает, что вы собираете данные, не застревая в бесконечном цикле, который съедает ваш таймаут запроса.
Раньше обходным путем была отправка запроса с отключенными редиректами, ручной парсинг заголовка Location и отправка еще одного запроса. Это минимум два вызова API, вдвое большая задержка (latency) и код, который вам нужно поддерживать. Теперь это один вызов с числом.
Сырые бинарные ответы с returnBuffer
Когда вы собираете изображения, PDF-файлы или payloads protobuf, декодирование текста уничтожает данные. Библиотека HTTP предполагает, что ответ является текстом, применяет определение кодировки и тихо искажает каждый байт, который не подходит. Protobuf становится нечитаемым. Заголовки изображений ломаются. В итоге вы получаете поврежденные файлы и никакого очевидного сообщения об ошибке, объясняющего причину.
returnBuffer говорит API полностью пропустить декодирование текста.
curl -X POST "https://eu.api.foura.ai/v1/request" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"url": "https://example.com/product-image.jpg",
"returnBuffer": true
}'
Тело ответа возвращается в виде сырых байтов (закодированных в base64 в JSON-ответах). Декодируйте его на своей стороне, и вы получите именно то, что отправил сервер. Никаких предположений о кодировке, никакой конвертации, никаких тихих повреждений.
Это был один из самых частых тикетов в поддержку, которые мы видели: пользователи собирали изображения продуктов или PDF-каталоги и получали файлы, которые не открывались. Исправление всегда было одним и тем же, но теперь для этого есть флаг вместо обходного пути.
Влияние
Обе функции сокращают количество вызовов API на задачу. followRedirects устраняет циклы ручного отслеживания редиректов. returnBuffer устраняет цикл «запросить, понять, что данные повреждены, запросить снова с другими настройками».
Для целей с большим количеством редиректов (партнерские ссылки, сокращатели URL, цепочки отслеживания e-commerce) мы видели снижение количества запросов на 40-60% при раннем тестировании, когда пользователи переходили с ручной обработки редиректов на followRedirects. А для задач сбора бинарных данных (изображения продуктов, загрузка документов) returnBuffer превращает многошаговый обходной путь в одну опцию (ранние результаты).
Это не броские функции. Это то, о чем вы не задумываетесь, пока ваш скрейпер не сломается в 3 часа ночи из-за того, что сайт добавил лишний прыжок редиректа в свой процесс оформления заказа.
Для опытных пользователей
Объедините followRedirects с валидацией ответа для точного контроля над цепочками редиректов. Следуйте по редиректам, но сбрасывайте запрос, если конечный пункт назначения упирается в стену:
curl -X POST "https://eu.api.foura.ai/v1/request" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"url": "https://example.com/product/12345",
"followRedirects": 5,
"unblocker": true,
"validate": {
"status": { "fail": [403, 503] },
"data": { "fail": ["Access Denied", "captcha"] }
}
}'
Это позволяет пройти до пяти редиректов, затем проверяет финальный ответ. Если сайт перенаправил вас на страницу с CAPTCHA или на заглушку доступа, запрос чисто завершается с ошибкой. Никаких мусорных данных, которые нужно фильтровать на следующих этапах.
Для сбора бинарных данных используйте returnBuffer вместе с запросами HEAD, когда вам нужно проверить типы контента перед загрузкой больших файлов. FourA корректно обрабатывает HEAD, поэтому вы можете просматривать заголовки, не запрашивая тело. Проверьте Content-Type, решите, стоит ли его скачивать, затем сделайте полный запрос с returnBuffer: true.
И если вы используете browser tasks для целей с большим количеством JavaScript, обратите внимание, что эти опции применяются к прямому движку HTTP. Запросы браузера обрабатывают редиректы через встроенную навигацию браузера, которая следует за ними по умолчанию без ограничений.
Что дальше
Мы работаем над тем, чтобы предоставить больше контроля на уровне запросов через API: пользовательское разрешение DNS, настройка таймаута для каждой фазы и опции обработки сертификатов. Цель состоит в том, чтобы получить полную мощь анблокера через чистый интерфейс REST, без накладных расходов на инфраструктуру.
Если вам нужна какая-то конкретная опция, мы вас слушаем. Дашборд уже показывает, как выполняются ваши запросы с этими новыми опциями, так что вы можете сами оценить разницу.