Prøv et Scrapy-GET igen gennem en anden proxy

At ændre response.request.meta ændrer et Python-objekt. For at hente igen skal Scrapy have en anden Request at planlægge.

For et GET, som dit callback udtrykkeligt beslutter at prøve igen, kan Scrypts offentlige genforsøgs-hjælper holde genforsøgsregnskabet med den nye anmodning:

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 edderkoppehjælper. Kalderen skal returnere eller yielde den resulterende Request, når en er tilgængelig. None betyder, at hjælperen afviste endnu et genforsøg inden for den gældende grænse.

Genforsøgs-hjælperen kopierer anmodningen, opdaterer dens genforsøgsantal og leverer den planlæggeradfærd, der passer til et genforsøg. Hvis man blot yielder samme URL som en almindelig ny anmodning, kan man i stedet ramme filtrering af dubletter.

Brug en proxy-URL, som den aktiverede HttpProxyMiddleware understøtter. Ved genforsøg af tilladte offentlige GET-anmodninger kan en uautentificeret HTTP-kandidat fra HTTP-proxylisten levere proxy_url. Rydning af et tidligere vedhæftet proxy-authorization-felt undgår at føre en gammel mellemmands header ind i dette valg; lad middleware udlede den nye konto fra den nye proxy-URL, når det er relevant.

Hold dette valg på callback-niveau adskilt fra RetryMiddlewares automatiske håndtering af sine konfigurerede fejl. Beslut, hvilket lag der ejer genforsøget, så operationen ikke bruger to uafhængige budgetter. Eksemplet handler om gentageligt GET-arbejde, ikke et løfte om, at gentagelse af en vilkårlig indsendt transaktion er sikker.