Scrapy-proxy-middleware: Request kontra None som returverdier
Gi kontrollen tilbake etter at du har tildelt en Scrapy-proxy, i stedet for å utilsiktet planlegge den samme forespørselen på nytt før den lastes ned.
Proxyadressen endres i loggen. Destinasjonen dukker aldri opp i proxyens tilgangslogg. Sjekk om middlewaren din i det hele tatt slipper forespørselen frem til nedlasteren.
I Scopys nedlaster-middleware betyr det å returnere en Request at forespørselen planlegges på nytt. Det betyr ikke «fortsett å sende dette objektet med metadataene jeg nettopp endret».
For en velger som bare velger en rute, er den viktige formen:
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øtter. Velgeren må returnere et gyldig endepunkt og håndtere en utilgjengelig pool eksplisitt. En offentlig crawl som tillater offentlige mellommenn, kan hente HTTP-kandidater fra HTTP-proxylisten for den returverdien.
Å returnere None lar resten av forespørsels-middlewaren og nedlasteren fortsette. Å returnere en annen Request er nyttig når du bevisst erstatter eller prøver arbeid på nytt, men det trenger en grunn og en utgangsbetingelse.
En rotator som returnerer den samme forespørselen hver gang, kan kjøre sin egen utvelgelseskode gang på gang uten noen gang å opprette en forbindelse til destinasjonen. Å øke tidsavbrudd eller åpne flere proxyporter kan ikke reparere den kontrollflytløkken.
Undersøk middleware-inngang, returatferd og det første faktiske nettverksforsøket som separate hendelser. En logglinje som sier «proxy valgt», beviser bare at velgeren kjørte. Den beviser ikke at en forespørsel med det valgte endepunktet ble sendt.