Scrapy-proxymiddleware: Request versus None als retourwaarden
Geef de controle terug nadat je een Scrapy-proxy hebt toegewezen, in plaats van hetzelfde verzoek vóór het downloaden onbedoeld opnieuw in te plannen.
Het proxyadres verandert in het log. De bestemming verschijnt nooit in het toegangslog van de proxy. Controleer of je middleware het verzoek überhaupt bij de downloader laat komen.
In de downloader-middleware van Scrapy betekent het teruggeven van een Request dat dat verzoek opnieuw wordt ingepland. Het betekent niet „blijf dit object versturen met de metadata die ik net heb gewijzigd“.
Voor een selector die alleen een route kiest, is de belangrijke vorm:
def process_request(self, request):
request.meta['proxy'] = self.choose_proxy()
return None
Dit fragment toont de huidige hookvorm; gebruik de middleware-interface die de geïnstalleerde Scrapy-versie ondersteunt. De selector moet een geldig eindpunt teruggeven en een niet-beschikbare pool expliciet afhandelen. Een publieke crawl die publieke tussenpersonen toestaat, kan HTTP-kandidaten putten uit de HTTP-proxylijst voor die retourwaarde.
None teruggeven laat de rest van de request-middleware en de downloader doorgaan. Een andere Request teruggeven is nuttig wanneer je werk bewust vervangt of opnieuw probeert, maar het vereist een reden en een exitvoorwaarde.
Een rotator die elke keer hetzelfde verzoek teruggeeft, kan zijn eigen selectiecode herhaaldelijk uitvoeren zonder ooit een verbinding met de bestemming te maken. Time-outs verhogen of meer proxy-poorten openen kan die control-flow-lus niet repareren.
Onderzoek middleware-toegang, retourgedrag en de eerste echte netwerkpoging als afzonderlijke gebeurtenissen. Een logregel die „proxy geselecteerd“ zegt, bewijst alleen dat de selector liep. Hij bewijst niet dat een verzoek met het geselecteerde eindpunt is verzonden.