ניסיון חוזר של GET ב-Scrapy דרך פרוקסי אחר

שינוי response.request.meta משנה אובייקט Python. כדי לבצע הורדה נוספת, יש לתת ל-Scrapy Request אחר לתזמון.

עבור GET שה-callback שלכם מחליט במפורש לנסות שוב, עוזר הניסיון החוזר הציבורי של Scrapy יכול לשמור את חשבונאות הניסיונות עם הבקשה החדשה:

from scrapy.downloadermiddlewares.retry import get_retry_request

def retry_through(self, response, proxy_url):
    retry = get_retry_request(
        response.request,
        spider=self,
        reason='choose_another_proxy',
    )
    if retry is None:
        return None
    retry.meta['proxy'] = proxy_url
    retry.headers.pop('Proxy-Authorization', None)
    return retry

זהו עוזר של spider. הקורא חייב להחזיר או ל-yield את ה-Request שמתקבל כשהוא זמין. None פירושו שהעוזר סירב לניסיון חוזר נוסף במסגרת המגבלה הרלוונטית.

עוזר הניסיון החוזר מעתיק את הבקשה, מעדכן את מונה הניסיונות שלה ומספק את התנהגות המתזמן המתאימה לניסיון חוזר. לעומת זאת, yield של אותו URL כבקשה חדשה רגילה עלול להיתקל בסינון כפילויות.

השתמשו בכתובת פרוקסי שנתמכת בידי HttpProxyMiddleware הפעיל. לניסיונות חוזרים של בקשות GET ציבוריות מותרות, מועמד HTTP ללא אימות מרשימת פרוקסי ה-HTTP יכול לספק proxy_url. ניקוי שדה proxy-authorization שהוצמד קודם מונע העברת כותרת של מתווך ישן לבחירה הזו; הניחו ל-middleware לגזור את החשבון החדש מכתובת הפרוקסי החדשה כשזה רלוונטי.

הפרידו את הבחירה ברמת ה-callback מהטיפול האוטומטי של RetryMiddleware בכשלים המוגדרים שלו. החליטו איזו שכבה מחזיקה בניסיון החוזר כדי שהפעולה לא תצרוך שני תקציבים בלתי תלויים. הדוגמה עוסקת בעבודת GET הניתנת להרצה חוזרת, לא בהבטחה שחזרה על עסקה שנשלחה באופן שרירותי בטוחה.