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 у метаданых запыту адказу. Яны могуць захаваць шлях да канчатковага выніку, не пакідаючы перанакіраванні адключанымі на ўвесь абыход.

Канчатковы адказ не абавязкова тая старонка, якую меў на ўвазе дадатак. Захоўвайце прызначэнне і змест адказу разам з дыягностыкай маршрутызацыі.

Падобныя артыкулы