Scrapy-ն կարող է ցույց տալ վերահասցեավորումը նախքան այն հետևելը

Պրոքսիով 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-ը։ Դրանք կարող են պահպանել դեպի վերջնական արդյունք տանող ուղին՝ չթողնելով վերահասցեավորումները անջատված ամբողջ սկանավորման ընթացքում։

Վերջնական պատասխանը ինքնաբերաբար այն էջը չէ, ինչ նախատեսել էր հավելվածը։ Պահեք նպատակակետը և պատասխանի բովանդակությունը երթուղավորման ախտորոշման հետ միասին։