Prøv en Scrapy-GET på nytt via 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 velger å prøve på nytt, kan Scrapys offentlige hjelper for nye forsøk føre 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 hjelper for edderkoppen. Den som kaller, må returnere eller yielde den resulterende Requesten når en finnes. 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 til et nytt forsøk. Å yielde samme URL som en helt vanlig ny forespørsel kan derimot ende i 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 skaffe proxy_url. Å slette et tidligere festet proxy-authorization-felt hindrer at headeren til en gammel mellommann blir med inn i dette valget; la middleware utlede den nye kontoen fra den nye proxy-URLen der det er aktuelt.

Hold dette valget på callback-nivå atskilt fra RetryMiddlewares automatiske behandling av de konfigurerte feilene. Bestem hvilket lag som eier det nye forsøket, så operasjonen ikke bruker to uavhengige budsjetter. Eksempelet gjelder gjentakbart GET-arbeid, ikke et løfte om at gjentakelse av en vilkårlig innsendt transaksjon er trygg.