Prøv ein Scrapy-GET på nytt gjennom ein annan proxy

Å endre response.request.meta endrar eit Python-objekt. For å hente på nytt må Scrapy få ein annan Request å planleggje.

For ein GET som callbacken din uttrykkeleg avgjer å prøve på nytt, kan den offentlege hjelparen for nye forsøk i Scrapy halde rekneskapen med den nye førespurnaden:

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 ein edderkopphjelpar. Den som kallar, må returnere eller yielde den resulterande Requesten når ein er tilgjengeleg. None tyder på at hjelparen avslo eit nytt forsøk innanfor den gjeldande grensa.

Hjelparen kopierer førespurnaden, oppdaterer teljaren for nye forsøk og gjev planleggjaråtferda som høver for eit nytt forsøk. Å berre yielde same URL som ein vanleg ny førespurnad kan i staden møte duplikatfiltrering.

Bruk ein proxy-URL som den aktiverte HttpProxyMiddleware støttar. For nye forsøk på tillatne offentlege GET-førespurnader kan ein uautentisert HTTP-kandidat frå HTTP-proxylista levere proxy_url. Å fjerne eit tidlegare vedlagt proxy-authorization-felt hindrar at hovudet til ein gammal mellmann følgjer med inn i dette valet; la middleware utleie den nye kontoen frå den nye proxy-URL-en når det er relevant.

Hald dette valet på callback-nivå skilt frå RetryMiddleware sin automatiske handsaming av dei konfigurerte feila sine. Avgjer kva lag som eig det nye forsøket, slik at operasjonen ikkje brukar to uavhengige budsjett. Dømet gjeld gjentakbart GET-arbeid, ikkje eit løfte om at gjentaking av ein vilkårleg innsend transaksjon er trygg.