Scrapy peut afficher la redirection avant de la suivre

Exposez temporairement le statut de redirection initial et l'en-tête Location d'une GET proxifiée via les métadonnées de la requête, en gardant le traitement des redirections séparé du filtrage des erreurs HTTP.

Une GET proxifiée peut atteindre un serveur puis suivre des redirections jusqu'à ce que l'échec final masque la première réponse. Exposez cette réponse initiale pour le diagnostic :

request = scrapy.Request(
    'https://service.example/page',
    callback=inspect_redirect,
    meta={
        'proxy': 'http://proxy.example:8080',
        'dont_redirect': True,
        'handle_httpstatus_list': [301, 302, 303, 307, 308],
    },
)

Planifiez cette requête via le flux de démarrage ou de callback existant de l'araignée. Pour une sonde autorisée de page publique, la liste de proxys HTTP fournit des candidats pour l'URL de proxy de la requête. inspect_redirect doit enregistrer le statut de la réponse et l'en-tête Location au lieu de la suivre à nouveau aveuglément.

dont_redirect arrête la redirection automatique pour cette requête. handle_httpstatus_list permet aux statuts nommés d'atteindre le callback au lieu d'être rejetés par le filtrage des erreurs HTTP. Ces réglages relèvent de responsabilités différentes du middleware.

Vérifiez ce que la redirection sélectionne : une URL canonique prévue, un schéma ou un nom d'hôte différent, une page de connexion ou un cycle répétitif. Un 302 reçu après un transport réussi est une observation différente de l'échec d'ouverture de la connexion au proxy.

Lorsque le traitement normal des redirections est rétabli, Scrapy expose redirect_urls et redirect_reasons dans les métadonnées de requête de la réponse. Ils peuvent conserver le chemin menant à un résultat final sans laisser les redirections désactivées pendant tout le crawl.

Une réponse terminale n'est pas automatiquement la page visée par l'application. Conservez la destination et le contenu de la réponse avec le diagnostic de routage.

Articles similaires