Försök igen med en Scrapy-GET via en annan proxy

Att ändra response.request.meta ändrar ett Python-objekt. För att hämta igen måste Scrapy få en annan Request att schemalägga.

För en GET som din callback uttryckligen beslutar att försöka igen kan Scrapys offentliga återförsökshjälpare hålla återförsöksbokföringen med den nya begäran:

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

Detta är en spindelhjälpare. Anroparen måste returnera eller yielda den resulterande Requesten när en är tillgänglig. None betyder att hjälparen avböjde ytterligare ett återförsök inom den tillämpliga gränsen.

Återförsökshjälparen kopierar begäran, uppdaterar dess återförsöksräknare och tillhandahåller schemaläggarbeteendet som passar för ett återförsök. Att bara yielda samma URL som en vanlig ny begäran kan i stället stöta på dubblettfiltrering.

Använd en proxy-URL som den aktiverade HttpProxyMiddleware stöder. För återförsök av tillåtna offentliga GET-begäranden kan en oautentiserad HTTP-kandidat från HTTP-proxylistan tillhandahålla proxy_url. Att rensa ett tidigare bifogat proxy-authorization-fält förhindrar att en gammal mellanhands header följer med in i detta val; låt middleware härleda det nya kontot från den nya proxy-URL:en när det är relevant.

Håll detta val på callback-nivå åtskilt från RetryMiddlewares automatiska hantering av sina konfigurerade fel. Bestäm vilket lager som äger återförsöket så att operationen inte förbrukar två oberoende budgetar. Exemplet gäller upprepningsbart GET-arbete, inte ett löfte om att upprepning av en godtyckligt inskickad transaktion är säker.