Middleware de proxy Scrapy : Request contre None comme valeurs de retour

L'adresse du proxy change dans le journal. La destination n'apparaît jamais dans le journal d'accès du proxy. Vérifiez si votre middleware laisse la requête atteindre le téléchargeur.

Dans le middleware du téléchargeur de Scrapy, renvoyer un Request signifie replanifier cette requête. Cela ne signifie pas « continuez à envoyer cet objet avec les métadonnées que je viens de modifier ».

Pour un sélecteur qui ne choisit qu'une route, la forme importante est :

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

Cet extrait montre la forme actuelle du crochet ; utilisez l'interface de middleware prise en charge par la version de Scrapy installée. Le sélecteur doit renvoyer un point de terminaison valide et gérer explicitement un pool indisponible. Un crawl public qui autorise des intermédiaires publics peut tirer des candidats HTTP de la liste de proxys HTTP pour cette valeur de retour.

Renvoyer None laisse le reste du middleware de requête et le téléchargeur continuer. Renvoyer un autre Request est utile lorsque vous remplacez ou réessayez volontairement un travail, mais cela demande une raison et une condition de sortie.

Un rotateur qui renvoie la même requête à chaque fois peut exécuter à répétition son propre code de sélection sans jamais établir de connexion vers la destination. Augmenter les délais d'attente ou ouvrir davantage de ports proxy ne peut pas réparer cette boucle de flux de contrôle.

Examinez l'entrée du middleware, le comportement de retour et la première tentative réseau réelle comme des événements distincts. Une ligne de journal indiquant « proxy sélectionné » prouve seulement que le sélecteur s'est exécuté. Elle ne prouve pas qu'une requête utilisant le point de terminaison sélectionné a été envoyée.