Scrapy може показати перенаправлення, перш ніж перейти за ним

Тимчасово розкрийте початковий статус перенаправлення й заголовок Location проксійованого GET через метадані запиту, відокремивши обробку перенаправлень від фільтрації помилок HTTP.

Проксійований GET може дійти до сервера й далі йти за перенаправленнями, доки підсумкова помилка не приховає першу відповідь. Розкрийте цю першу відповідь для діагностики:

request = scrapy.Request(
    'https://service.example/page',
    callback=inspect_redirect,
    meta={
        'proxy': 'http://proxy.example:8080',
        'dont_redirect': True,
        'handle_httpstatus_list': [301, 302, 303, 307, 308],
    },
)

Заплануйте цей запит через наявний потік запуску або callback павука. Для дозволеної перевірки публічної сторінки список HTTP-проксі пропонує кандидатів для проксі-URL запиту. inspect_redirect має записувати статус відповіді й заголовок Location, а не знову сліпо йти за ним.

dont_redirect зупиняє автоматичне перенаправлення для цього запиту. handle_httpstatus_list дозволяє зазначеним статусам дійти до callback, замість того щоб бути відхиленими фільтрацією помилок HTTP. Ці налаштування стосуються різних обов'язків middleware.

Перевірте, що обирає перенаправлення: потрібний канонічний URL, іншу схему або ім'я хоста, сторінку входу чи повторюваний цикл. Отриманий після успішного передавання 302 — це інше спостереження, ніж невдача відкриття проксі-з'єднання.

Коли звичайну обробку перенаправлень відновлено, Scrapy розкриває redirect_urls і redirect_reasons у метаданих запиту відповіді. Вони можуть зберегти шлях до підсумкового результату, не залишаючи перенаправлення вимкненими на весь обхід.

Підсумкова відповідь не обов'язково є сторінкою, яку мав на увазі застосунок. Зберігайте призначення й вміст відповіді разом із діагностикою маршрутизації.

Схожі статті