response.request.meta बदलल्याने Python ऑब्जेक्ट बदलतो. आणखी एक डाउनलोड करण्यासाठी Scrapy ला शेड्यूल करण्यासाठी दुसरी Request द्यावी लागते.

तुमचा callback स्पष्टपणे पुन्हा प्रयत्न करण्याचे ठरवत असलेल्या GET साठी, 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 सहाय्यक आहे. कॉलरने निकाली Request उपलब्ध असल्यास परत द्यावी किंवा yield करावी. None म्हणजे सहाय्यकाने लागू मर्यादेत आणखी एक पुनः प्रयत्न नाकारला.

पुनः प्रयत्न सहाय्यक विनंतीची प्रत बनवतो, तिचा पुनः प्रयत्न मोजणारा अद्ययावत करतो आणि पुनः प्रयत्नासाठी योग्य शेड्यूलर वर्तन पुरवतो. तोच URL सामान्य नवीन विनंती म्हणून yield केल्यास त्याऐवजी डुप्लिकेट गाळणीत अडकू शकते.

सक्रिय HttpProxyMiddleware ला समर्थित असलेला प्रॉक्सी URL वापरा. अनुमत सार्वजनिक GET विनंत्यांच्या पुनः प्रयत्नांसाठी, HTTP प्रॉक्सी यादीमधील प्रमाणीकरण नसलेला HTTP उमेदवार proxy_url पुरवू शकतो. पूर्वी जोडलेले proxy-authorization फील्ड साफ केल्याने जुन्या मध्यस्थाचे हेडर या निवडीत जात नाही; लागू असल्यास मिडलवेअरला नवीन प्रॉक्सी URL वरून नवे खाते मिळवू द्या.

ही callback-स्तरीय निवड RetryMiddleware च्या संरचित अपयशांच्या स्वयंचलित हाताळणीपासून वेगळी ठेवा. पुनः प्रयत्न कोणत्या स्तराचा आहे हे ठरवा, जेणेकरून क्रिया दोन स्वतंत्र बजेट खर्च करणार नाही. उदाहरण पुन्हा चालवता येणाऱ्या GET कामाबद्दल आहे, कोणताही सबमिट केलेला व्यवहार पुन्हा करणे सुरक्षित आहे असे वचन नाही.

संबंधित लेख