Een Scrapy-GET opnieuw proberen via een andere proxy

response.request.meta wijzigen wijzigt een Python-object. Voor nog een download moet Scrapy een andere Request krijgen om te plannen.

Voor een GET die je callback expliciet opnieuw wil proberen, kan Scrapy's openbare retry-helper de retry-boekhouding bij het nieuwe verzoek houden:

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

Dit is een spider-helper. De aanroeper moet de resulterende Request teruggeven of yielden wanneer er een beschikbaar is. None betekent dat de helper nog een retry binnen de geldende limiet heeft geweigerd.

De retry-helper kopieert het verzoek, werkt de retry-teller bij en levert het scheduler-gedrag dat bij een retry past. Alleen dezelfde URL yielden als een gewoon nieuw verzoek kan juist op duplicaatfiltering stuiten.

Gebruik een proxy-URL die de ingeschakelde HttpProxyMiddleware ondersteunt. Voor retries van toegestane openbare GET-verzoeken kan een niet-geauthenticeerde HTTP-kandidaat uit de HTTP-proxylijst proxy_url leveren. Een eerder toegevoegd proxy-authorization-veld wissen voorkomt dat de header van een oude tussenpartij in deze keuze terechtkomt; laat de middleware het nieuwe account van de nieuwe proxy-URL afleiden wanneer dat van toepassing is.

Houd deze keuze op callback-niveau gescheiden van de automatische afhandeling door RetryMiddleware van zijn geconfigureerde fouten. Bepaal welke laag de retry bezit, zodat de bewerking niet twee onafhankelijke budgetten verbruikt. Het voorbeeld gaat over herhaalbaar GET-werk, niet over de belofte dat het herhalen van een willekeurige ingediende transactie veilig is.