Scrapy povas montri la alidirektadon antaŭ ol sekvi ĝin

Proksiita GET povas atingi servilon kaj poste sekvi alidirektadojn ĝis la fina malsukceso kaŝas la unuan respondon. Malkaŝu tiun komencan respondon por diagnozo:

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

Planu ĉi tiun peton per la ekzistanta komenca aŭ callback-fluo de la araneo. Por permesita provo de publika paĝo, la HTTP-proksa listo provizas kandidatojn por la proksa URL de la peto. inspect_redirect devus registri la respondan staton kaj la Location-kapon anstataŭ blinde sekvi ĝin denove.

dont_redirect haltigas aŭtomatan alidirektadon por ĉi tiu peto. handle_httpstatus_list lasas la nomitajn statojn atingi la callback anstataŭ esti malakceptitaj de HTTP-erara filtrado. La agordoj rilatas al malsamaj respondecoj de middleware.

Kontrolu, kion la alidirektado elektas: celatan kanonikan URL, alian skemon aŭ gastignomon, ensalutan paĝon aŭ ripetiĝantan ciklon. 302 ricevita post sukcesa transporto estas malsama observado ol malsukceso malfermi la proksan konekton.

Kiam normala alidirekta traktado estas restarigita, Scrapy malkaŝas redirect_urls kaj redirect_reasons en la petometadatenoj de la respondo. Tiuj povas konservi la vojon al fina rezulto sen lasi alidirektadojn malŝaltitaj por la tuta rampado.

Fina respondo ne aŭtomate estas la paĝo, kiun la aplikaĵo intencis. Konservu la celon kaj respondan enhavon kune kun la enkursiga diagnozo.