Prøv en Scrapy-GET på nytt gjennom en annen proxy

Å endre response.request.meta endrer et Python-objekt. For å hente på nytt må Scrapy få en annen Request å planlegge.

For en GET som callbacken din uttrykkelig bestemmer seg for å prøve på nytt, kan Scrapys offentlige hjelper for nye forsøk holde regnskapet med den nye forespørselen:

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

Dette er en edderkopphjelper. Den som kaller, må returnere eller yielde den resulterende Requesten når en er tilgjengelig. None betyr at hjelperen avslo nok et nytt forsøk innenfor den gjeldende grensen.

Hjelperen kopierer forespørselen, oppdaterer telleren for nye forsøk og gir planleggeratferden som passer for et nytt forsøk. Å bare yielde samme URL som en vanlig ny forespørsel kan i stedet møte duplikatfiltrering.

Bruk en proxy-URL som den aktiverte HttpProxyMiddleware støtter. For nye forsøk på tillatte offentlige GET-forespørsler kan en uautentisert HTTP-kandidat fra HTTP-proxylisten levere proxy_url. Å fjerne et tidligere vedlagt proxy-authorization-felt hindrer at en gammel mellommanns header følger med inn i dette valget; la middleware utlede den nye kontoen fra den nye proxy-URLen når det er relevant.

Hold dette valget på callback-nivå atskilt fra RetryMiddlewares automatiske håndtering av sine konfigurerte feil. Avgjør hvilket lag som eier det nye forsøket, slik at operasjonen ikke bruker to uavhengige budsjetter. Eksemplet gjelder gjentakbart GET-arbeid, ikke et løfte om at gjentakelse av en vilkårlig innsendt transaksjon er trygg.