Një GET përmes proxy mund të arrijë një server dhe më pas të ndjekë ridrejtime derisa dështimi përfundimtar fsheh përgjigjen e parë. Ekspozo atë përgjigje fillestare për diagnostikim:

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],
    },
)

Planifiko këtë kërkesë përmes rrjedhës ekzistuese të nisjes ose callback të merimangës. Për një provë të lejuar të faqes publike, lista e proxy-ve HTTP ofron kandidatë për URL-në e proxy të kërkesës. inspect_redirect duhet të regjistrojë statusin e përgjigjes dhe kokën Location në vend që ta ndjekë përsëri verbërisht.

dont_redirect ndalon ridrejtimin automatik për këtë kërkesë. handle_httpstatus_list lejon statuset e përmendura të arrijnë callback në vend që të refuzohen nga filtrimi i gabimeve HTTP. Këto cilësime kanë të bëjnë me përgjegjësi të ndryshme të middleware.

Kontrollo çfarë zgjedh ridrejtimi: një URL kanonike e synuar, një skemë ose emër hosti tjetër, një faqe hyrjeje ose një cikël që përsëritet. Një 302 i marrë pas një transporti të suksesshëm është një vëzhgim tjetër nga dështimi për të hapur lidhjen me proxy.

Kur trajtimi normal i ridrejtimeve rikthehet, Scrapy ekspozon redirect_urls dhe redirect_reasons në metadata e kërkesës së përgjigjes. Këto mund të ruajnë rrugën drejt një rezultati përfundimtar pa i lënë ridrejtimet të çaktivizuara gjatë gjithë zvarritjes.

Një përgjigje përfundimtare nuk është automatikisht faqja që aplikacioni synonte. Mbaj destinacionin dhe përmbajtjen e përgjigjes së bashku me diagnostikimin e rrugëzimit.

Artikuj të ngjashëm