Ripeti Scrapy GET tra alia prokura servilo

Uzu la ripetan helpilon de Scrapy por plani novan peton kun nova prokura servilo, respektante la ripetan buĝeton.

Ŝanĝi response.request.meta ŝanĝas Python-objekton. Por fari alian elŝuton, donu al Scrapy alian Request por plani.

Por GET, kiun via callback eksplicite decidas ripeti, la publika ripeta helpilo de Scrapy povas teni la ripetan kalkulon kun la nova peto:

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

Ĉi tio estas aranea helpilo. La vokanto devas redoni aŭ yieldi la rezultan Request kiam ĝi haveblas. None signifas, ke la helpilo rifuzis plian ripeton sub la valida limo.

La ripeta helpilo kopias la peton, ĝisdatigas ĝian ripetan nombron kaj provizas la planilan konduton taŭgan por ripeto. Se vi simple yieldas la saman URL kiel ordinaran novan peton, vi povas anstataŭe renkonti filtradon de duplikatoj.

Uzu prokuran URL-on subtenatan de la ŝaltita HttpProxyMiddleware. Por ripetoj de permesitaj publikaj GET-petoj, neaŭtentikigita HTTP-kandidato el la HTTP-prokura listo povas provizi proxy_url. Forigi antaŭe aligitan kampon proxy-authorization evitas porti kaplinion de malnova peranto en ĉi tiun elekton; lasu la middlewaro derivi la novan konton el la nova prokura URL kiam aplikeble.

Tenadu ĉi tiun elekton je callback-nivelo aparte de la aŭtomata traktado de RetryMiddleware de ĝiaj agorditaj malsukcesoj. Decidu, kiu tavolo posedas la ripeton, por ke la operacio ne konsumu du sendependajn buĝetojn. La ekzemplo koncernas ripeteblan GET-laboron, ne promeson, ke ripeti arbitran senditan transakcion estas sekura.

Rilataj artikoloj