Scrapy-proksiemiddewlare: Request teenoor None as terugkeerwaarde
Gee beheer terug nadat jy 'n Scrapy-proksie toegewys het, in plaas daarvan om dieselfde versoek onbedoeld te herbeplan voordat dit afgelaai word.
Die proksieadres verander in die log. Die bestemming verskyn nooit in die proksie se toegangslog nie. Kyk of jou middewlare die versoek hoegenaamd by die aflaaier laat uitkom.
In Scrapy se aflaaier-middewlare beteken die teruggee van 'n Request dat daardie versoek herbeplan word. Dit beteken nie “gaan voort om hierdie objek met die metadata wat ek pas verander het, te stuur” nie.
Vir 'n keurder wat net 'n roete kies, is die belangrike vorm:
def process_request(self, request):
request.meta['proxy'] = self.choose_proxy()
return None
Hierdie fragment wys die huidige haakvorm; gebruik die middewlare-koppelvlak wat die geïnstalleerde Scrapy-weergawe ondersteun. Die keurder moet 'n geldige eindpunt teruggee en 'n onbeskikbare poel eksplisiet hanteer. 'n Openbare kruip wat openbare tussengangers toelaat, kan HTTP-kandidate uit die HTTP-proksielys vir daardie terugkeerwaarde put.
Die teruggee van None laat die oorblywende versoek-middewlare en die aflaaier voortgaan. Die teruggee van 'n ander Request is nuttig wanneer jy werk doelbewus vervang of herprobeer, maar dit het 'n rede en 'n uitgangsvoorwaarde nodig.
'n Rotator wat elke keer dieselfde versoek teruggee, kan herhaaldelik sy eie keusekode laat loop sonder om ooit 'n bestemmingsverbinding te maak. Om die timeouts te verhoog of meer proksiepoorte oop te maak, kan nie daardie beheervloeilus herstel nie.
Ondersoek middewlare-toetrede, terugkeergedrag en die eerste werklike netwerkpoging as afsonderlike gebeure. 'n Logreël wat “gekose proksie” sê, bewys net dat die keurder geloop het. Dit bewys nie dat 'n versoek met die gekose eindpunt gestuur is nie.