Proxys par requête avec le middleware de proxy HTTP de Scrapy
Utilisez les métadonnées de requête de Scrapy et son intergiciel de proxy avant de copier un ancien intergiciel d'authentification personnalisé dans un crawler.
L'intergiciel de proxy HTTP de Scrapy lit un proxy à partir des métadonnées de la requête :
yield scrapy.Request(
'https://example.com/',
callback=self.parse,
meta={'proxy': 'http://203.0.113.10:8080'},
)Remplacez le point de terminaison de la documentation et laissez l'intergiciel activé. La liste de proxys HTTP propose des candidats publics pour l'URL de cette requête. Cela choisit la route de la requête ; un pool de proxys a besoin d'une logique de sélection distincte.
L'authentification suit le point de terminaison sélectionné
L'intergiciel intégré gère les identifiants fournis via son URL de proxy prise en charge et l'en-tête d'autorisation associé. Échappez les caractères réservés de l'URL et évitez de journaliser cette URL.
Un intergiciel distinct ne devrait pas conserver un en-tête Basic pour le proxy précédent après le changement de point de terminaison. Laissez une seule couche gérer la route et ses identifiants ensemble.
Ordre de sélection et valeurs par défaut
Si un intergiciel de téléchargement personnalisé choisit le proxy, exécutez-le avant que l'intergiciel de proxy intégré ne traite la requête. Vérifiez l'ordre et l'API de la version installée ; les imports scrapy.contrib obsolètes appartiennent aux anciennes versions.
L'environnement du processus peut aussi fournir des valeurs par défaut propres au schéma. Pour une requête délibérément directe, utilisez le comportement spécial documenté des métadonnées proxy : une clé absente ne signifie pas forcément un accès direct.
Inspectez le résultat réel. Un 407 concerne l'authentification du proxy, tandis qu'une limite de débit ou un refus d'accès du site peuvent survenir après que la route a fonctionné correctement.