Scrapy-proxy-middleware: Request kontra None som returverdiar

Proxyadressa endrar seg i loggen. Destinasjonen dukkar aldri opp i tilgangsloggen til proxyen. Sjekk om middlewaren din i det heile slepp førespurnaden fram til nedlastaren.

I nedlastar-middlewaren til Scrapy tyder det å returnere ein Request at førespurnaden blir planlagd på nytt. Det tyder ikkje «hald fram med å sende dette objektet med metadataa eg nettopp endra».

For ein veljar som berre vel ei rute, er den viktige forma:

def process_request(self, request):
    request.meta['proxy'] = self.choose_proxy()
    return None

Dette utdraget viser dagens hook-form; bruk middleware-grensesnittet som den installerte Scrapy-versjonen støttar. Veljaren må returnere eit gyldig endepunkt og handsame ein utilgjengeleg pool eksplisitt. Ein offentleg crawl som tillèt offentlege mellommenn, kan hente HTTP-kandidatar frå HTTP-proxylista for den returverdien.

Å returnere None lèt resten av førespurnads-middlewaren og nedlastaren halde fram. Å returnere ein annan Request er nyttig når du med vilje byter ut eller prøver arbeid på nytt, men det treng ein grunn og ein utgangsvilkår.

Ein rotator som returnerer den same førespurnaden kvar gong, kan køyre sin eigen utvalskode om og om att utan nokon gong å opprette samband til destinasjonen. Å auke tidsavbrot eller opne fleire proxyportar kan ikkje reparere den kontrollflytløkka.

Undersøk middleware-inngang, returåtferd og det første faktiske nettverksforsøket som separate hendingar. Ei logglinje som seier «proxy vald», beviser berre at veljaren køyrde. Ho beviser ikkje at ein førespurnad med det valde endepunktet vart send.