يمكن لـ 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 في بيانات الطلب الوصفية للاستجابة. ويمكن لهذين الحفظ المسار المؤدي إلى نتيجة نهائية دون ترك إعادة التوجيه معطّلة طوال الزحف.

الاستجابة النهائية ليست تلقائيًا الصفحة التي قصدها التطبيق. احتفظ بالوجهة ومحتوى الاستجابة مع تشخيص التوجيه.