Repetir un GET de Scrapy a través doutro proxy

Cambiar response.request.meta cambia un obxecto de Python. Para facer outra descarga, hai que darlle a Scrapy outra Request que programar.

Para un GET que o seu callback decide repetir explicitamente, o axudante público de reintentos de Scrapy pode manter a contabilidade de reintentos coa solicitude nova:

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

Este é un axudante de spider. Quen o chama debe devolver ou facer yield da Request resultante cando haxa unha dispoñible. None significa que o axudante rexeitou outro reintento dentro do límite aplicable.

O axudante de reintentos copia a solicitude, actualiza o seu contador de reintentos e fornece o comportamento de planificador axeitado para un reintento. Facer yield da mesma URL como unha solicitude nova común pode en cambio atopar o filtrado de duplicados.

Use un URL de proxy compatible co HttpProxyMiddleware activo. Para reintentos de solicitudes GET públicas permitidas, un candidato HTTP sen autenticación da lista de proxies HTTP pode fornecer proxy_url. Borrar un campo proxy-authorization anexado antes evita arrastrar a cabeceira dun intermediario antigo a esta selección; deixe que o middleware derive a conta nova do URL de proxy novo cando corresponda.

Manteña esta escolla no nivel de callback separada do manexo automático de RetryMiddleware dos seus fallos configurados. Decida que capa posúe o reintento para que a operación non consuma dous orzamentos independentes. O exemplo trata de traballo GET reproducible, non dunha promesa de que repetir unha transacción enviada arbitraria sexa seguro.