प्रॉक्सी वाला 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],
    },
)

इस अनुरोध को स्पाइडर के मौजूदा start या callback प्रवाह से शेड्यूल करें। अनुमत सार्वजनिक-पृष्ठ जाँच के लिए, HTTP प्रॉक्सी सूची अनुरोध के प्रॉक्सी URL के लिए उम्मीदवार देती है। inspect_redirect को प्रतिक्रिया की स्थिति और Location हेडर रिकॉर्ड करना चाहिए, न कि उसका फिर से आँख मूँदकर पालन करना।

dont_redirect इस अनुरोध के लिए स्वचालित रीडायरेक्ट रोकता है। handle_httpstatus_list नामित स्थितियों को HTTP-त्रुटि फ़िल्टरिंग द्वारा अस्वीकृत होने के बजाय callback तक पहुँचने देता है। ये सेटिंग्स middleware की अलग-अलग ज़िम्मेदारियों से जुड़ी हैं।

जाँचें कि रीडायरेक्ट क्या चुनता है: इच्छित कैनोनिकल URL, भिन्न स्कीम या होस्टनाम, लॉगिन पृष्ठ, या दोहराया जाने वाला चक्र। सफल परिवहन के बाद मिला 302, प्रॉक्सी कनेक्शन खोलने में विफलता से भिन्न अवलोकन है।

जब सामान्य रीडायरेक्ट हैंडलिंग बहाल होती है, तो Scrapy प्रतिक्रिया के अनुरोध मेटाडेटा में redirect_urls और redirect_reasons दिखाता है। ये पूरे क्रॉल के लिए रीडायरेक्ट अक्षम छोड़े बिना अंतिम परिणाम तक का मार्ग सुरक्षित रख सकते हैं।

अंतिम प्रतिक्रिया अपने आप वह पृष्ठ नहीं होती जिसका एप्लिकेशन ने इरादा किया था। गंतव्य और प्रतिक्रिया की सामग्री को रूटिंग निदान के साथ रखें।

संबंधित लेख