Dans le cadre de la gestion quotidienne des données en ligne et du web scraping, il est courant de rencontrer des messages proxy pointant des erreurs. Ces codes d’erreur sont des indicateurs essentiels des problèmes de fourniture de données liés aux proxys et jouent un rôle essentiel dans le diagnostic et la résolution des problèmes.
Cet article décrit les différents types de codes d’erreurs de proxys HTTP, en couvrant les différents scénarios, interprétations et conditions dans lesquels ils apparaissent fréquemment.
Codes d’erreurs de proxys
Les erreurs de proxys peuvent survenir pour diverses raisons, notamment une interruption du serveur ou des paramètres incohérents. La compréhension de ces détails vous permet de déterminer ce qui ne va pas afin de corriger plus facilement la situation.
Dans les sections suivantes, vous découvrirez les différents codes proxy ainsi que la façon de les dépanner et de les résoudre efficacement.
Codes 3xx : redirections
Un code d’état HTTP 3xx est utilisé pour les redirections, indiquant que l’agent utilisateur doit prendre des mesures supplémentaires pour finaliser la requête. Généralement, ce code implique que vous êtes redirigé vers une nouvelle URL en raison de modifications rédactionnelles ou d’une restructuration du site Web.
En matière de web scraping, vous devez gérer ces redirections pour maintenir une collecte de données précise et efficace.
301 : déplacé définitivement
Si vous recevez une erreur 301, cela signifie que la ressource que vous recherchez a été définitivement déplacée. Cela se produit souvent lorsqu’un site Web fait l’objet de mises à jour, telles que la refonte ou la réorganisation de son contenu.
Si vous rencontrez cette erreur, votre scraper doit transférer ses références URL vers le nouvel emplacement à partir des en-têtes de réponse :
response_data = requests.get('http://example.com/old-page')
if response_data.status_code == 301:
new_redirect_url = response_data.headers['Location']
response_data = requests.get(new_redirect_url)
Dans ce code, vous demandez à votre scraper d’obtenir l’emplacement de redirection qui provient de l’en-tête. Ensuite, il accède au contenu à son nouvel emplacement :
302 : trouvé (redirection temporaire)
Le code d’état 302 Found indique que la ressource à laquelle vous essayez d’accéder a été temporairement déplacée vers une autre URL. Dans ce cas, la modification n’est pas permanente et l’URL d’origine devrait redevenir viable à un moment donné. Cela se produit souvent lorsqu’un site Web est en cours de maintenance.
Lors d’un web scraping, il est important de configurer votre script pour gérer automatiquement les redirections, en veillant à ce que les URL stockées restent inchangées. Bien que de nombreuses bibliothèques HTTP, comme Python Requests, gèrent automatiquement les redirections 302, il est important de vérifier que ce comportement correspond à vos objectifs de scraping, en particulier lorsqu’il est nécessaire de préserver la méthode de la requête d’origine :
304 : non modifié
Si le contenu auquel vous essayez d’accéder n’a pas été mis à jour depuis la dernière requête validée, une erreur 304 s’affichera. Cette erreur contribue à améliorer l’efficacité des activités de web scraping, empêchant ainsi le téléchargement de données inutiles.
Si votre scraper accède à une page qui a déjà été téléchargée, des en-têtes de requête, tels que If-Modified-Since ou If-None-Match, peuvent être utilisés pour vérifier que le contenu n’est pas modifié :
import requests
# Correct header format and Python syntax
headers = {'If-Modified-Since': 'Sat, Oct 29 2024 19:43:31 GMT'}
# Making a GET request to the server with the headers
response = requests.get('http://example.com/page', headers=headers)
# Checking if the status code returned is 304
if response.status_code == 304:
print("Content has not changed.")
Dans ce code, vous commencez par tester si le code de réponse est 304. Si c’est le cas, Message Content has not changed s’affiche, et vous n’avez rien à faire :
307 : redirection temporaire
Une redirection temporaire, dont le code d’état est 307, vous indique que la ressource que vous essayez d’atteindre est temporairement placée sur une autre URL. Dans ce cas, la même méthode HTTP et le même corps de la requête d’origine peuvent être réutilisés avec l’URL redirigée. Cela diffère du code 302, où l’URL redirigée peut utiliser une méthode et un corps différents :
response = requests.post('http://examples.com/submit-form', data={'key': 'value'} )
if response.status_code == 307:
response = requests.post(response.headers['Location'], data={'key': 'value'})
Vous devez maintenir l’ordre lorsque vous redirigez un web crawler. Cela permet de garantir une collecte de données fiable et efficace tout en respectant la structure et le système de serveur du site Web cible. Le code suivant vérifie si l’état de la réponse est 307 ; si c’est le cas, les mêmes données dans le corps sont renvoyées au nouvel Emplacement spécifié dans l’en-tête de la réponse :
Codes 4xx : erreurs côté client
Les erreurs côté client sont signalées par une plage 4xx de codes d’état HTTP et résultent généralement d’un problème lié à la requête faite par le client. Souvent, ces erreurs entraînent la rectification des paramètres de la requête ou une amélioration opérationnelle des mécanismes d’authentification.
400 : demande incorrecte
L’erreur 400 Bad Request indique que le serveur n’a pas été en mesure de comprendre la requête. Dans le cadre d’un web scraping, cela se produit généralement lorsque l’en-tête de la requête n’est pas écrit correctement ou qu’il manque des parties.
Par exemple, si vous envoyez involontairement des informations dans le mauvais format (par exemple en envoyant du texte au lieu d’un contenu JSON), le serveur ne peut pas traiter la requête et celle-ci est rejetée. Pour résoudre ce problème, vous devez exécuter la validation avec soin et vous assurer que la syntaxe de la requête répond aux attentes du serveur.
Dans le cadre d’un web scraping, vous devez suivre plusieurs étapes pour vérifier que vos requêtes répondent aux attentes du serveur. Dans un premier temps, vous devez vous assurer de bien comprendre la structure du site Web ciblé. Vous pouvez utiliser les outils de développement du navigateur pour inspecter les éléments et découvrir comment les données sont formatées. En outre, vous devez implémenter des tests et une gestion des erreurs tout en vous assurant que vous utilisez des en-têtes appropriés dans vos requêtes :
401 : non autorisé
Une erreur 401 Unauthorized indique un échec ou une absence d’authentification requise pour accéder à une ressource. Dans le web scraping, cela se produit généralement lorsque vous essayez d’accéder à un contenu authentifié. Par exemple, l’accès à des données d’abonnement avec des informations d’identification incorrectes déclenche cette erreur. Pour éviter cela, assurez-vous d’inclure les bons en-têtes d’authentification dans vos requêtes :
403 : interdit
Une erreur 403 Forbidden signifie que le serveur a pu comprendre la requête, mais a refusé de vous autoriser à accéder à la ressource. Cela se produit fréquemment lors du web scraping d’un site Web dont les contrôles d’accès sont stricts. Vous rencontrez souvent cette erreur lorsque vous entrez dans une partie interdite d’un site Web. Par exemple, si vous vous authentifiez en tant qu’utilisateur et que vous essayez d’accéder aux publications d’un autre utilisateur, vous ne pourrez pas le faire, ne disposant pas de l’autorisation nécessaire :
Si vous recevez un message d’erreur 403, vérifiez l’autorisation en examinant vos clés ou vos informations d’identification. Si l’autorisation n’est pas disponible et que vous ne disposez pas d’informations d’identification valides, il est recommandé de ne pas supprimer ce contenu afin de vous conformer à la politique d’accès du site Web.
404 : introuvable
Lorsque le serveur ne trouve pas la ressource demandée, il renvoie l’erreur 404 Not Found.
Cela se produit souvent lorsque les URL utilisées dans le web scraping sont modifiées ou altérées, par exemple lorsqu’une page de produit est supprimée ou que son URL est modifiée sans redirection ni mise à jour.
Pour résoudre ce problème, vérifiez les URL de votre script de scraping et mettez-les à jour si nécessaire pour les aligner sur la structure actuelle du site Web :
Il est toujours recommandé de traiter les erreurs 404 présentes dans votre code.
Si vous utilisez Python et que le serveur n’a pas trouvé la ressource, vous pouvez demander à votre code de transmettre le bloc de code suivant afin que votre code ne s’arrête pas lorsque cette erreur se produit :
import requests
# List of URLs to fetch
urls = [
"http://example.com/nonexistentpage.html", # This should result in 404
"http://example.com" # This should succeed
]
for url in urls:
try:
response = requests.get(url)
if response.status_code == 404:
print(f"Error 404: URL not found: {url}")
# Continue to the next URL in the list
continue
print(f"Successfully retrieved data from {url}")
print(response.text[:200]) # Print the first 200 characters of the response content
except requests.exceptions.RequestException as e:
print(f"An error occurred while fetching {url}: {e}")
continue # Continue to the next URL even if a request exception occurs
print("Finished processing all URLs.")
Dans le code suivant, vous parcourez le tableau d’URL, puis vous essayez de récupérer le contenu de la page. En cas d’échec avec une erreur 400, le code passe à l’URL suivante du tableau.
407 : authentification par proxy requise
L’erreur 407 Proxy Authentication Required est déclenchée lorsque le client doit s’authentifier auprès du serveur proxy pour que la requête puisse être traitée. Cette erreur se produit fréquemment lors du web scraping lorsque le serveur proxy a besoin d’une authentification. Ceci est différent d’une erreur 401 lorsque l’authentification est requise pour accéder aux données relatives au site Web cible.
Par exemple, si vous rencontrez cette erreur lorsque vous utilisez un proxy privé pour accéder aux données d’un site Web ciblé, cela signifie que vous n’êtes pas authentifié. Pour résoudre ce problème, vous devez ajouter des informations d’authentification proxy valides dans vos requêtes :
408 : expiration de la requête
Un code d’état 408 Request Timeout indique que le serveur a attendu la requête trop longtemps. Cette erreur peut survenir lorsque votre scraper est trop lent ou si le serveur est surchargé, en particulier pendant les heures de pointe.
Lorsque la synchronisation des requêtes est optimisée et que de nouvelles tentatives sont mises en œuvre avec des mécanismes d’attente (backoff) exponentielle, ce problème peut être minimisé, car le serveur dispose de suffisamment de temps pour répondre :
429 : trop de requêtes
L’erreur 429 Too Many Requests est générée lorsqu’un utilisateur a envoyé un grand nombre de requêtes dans un court laps de temps. Cela se produit fréquemment lorsque les limites de débit de web scraping sur un site Web sont dépassées. Par exemple, si vous interrogez souvent un site Web, la limite de débit sera activée et vous ne pourrez plus récupérer de données.
Assurez-vous de respecter les limites de débit d’API du site Web ciblé et d’appliquer les meilleures pratiques de scraping, telles que le report des requêtes, afin d’éviter ce problème et de maintenir l’accès aux ressources nécessaires :
Codes 5xx : problèmes côté serveur
Les problèmes côté serveur sont signalés par une série 5xx de codes d’état HTTP et font référence à l’incapacité du serveur à répondre aux requêtes en raison de problèmes internes. Vous devez comprendre ces erreurs lors du web scraping, car elles nécessitent souvent une approche distincte de celle de la gestion des erreurs côté client.
500 : erreur interne du serveur
L’erreur 500 Internal Server Error est une réponse générique qui vous informe qu’une situation anormale s’est produite sur le serveur qui ne lui a pas permis de traiter la requête spécifique. Ce problème ne provient pas d’une erreur commise par le client, mais signifie plutôt que le problème provient du serveur lui-même.
Par exemple, lors d’un scraping de données, cette erreur peut se produire lors de la tentative d’accès à une page sur le serveur. Pour résoudre le problème, vous pouvez réessayer ultérieurement ou planifier vos projets de web scraping de manière à ce qu’ils soient exécutés en dehors des heures de pointe alors que le serveur n’est pas surchargé :
501 : non implémenté
L’erreur 501 Not Implemented se produit lorsque le serveur ne reconnaît pas la méthode de requête ou ne finalise pas cette méthode. Comme vous testez généralement les méthodes de votre crawler au préalable, cette erreur se produit rarement lors du web scraping, mais elle peut se produire si vous utilisez des méthodes HTTP atypiques.
Par exemple, si votre scraper est configuré pour utiliser des méthodes qui ne sont pas prises en charge par le serveur (par exemple PUT ou DELETE) et que celles-ci sont nécessaires à vos fonctions de web scraping, vous recevrez une erreur 501. Pour éviter cela, assurez-vous que si vos scripts de scraping utilisent des méthodes HTTP, celles-ci sont obligatoires partout :
502 : passerelle incorrecte
L’erreur 502 Bad Gateway indique que, bien qu’il ait agi en tant que passerelle ou proxy, le serveur a reçu une réponse inappropriée de la part du serveur de destination et a fait l’objet d’un accès pour répondre à la requête. Cela indique qu’il y a eu un problème de communication avec les serveurs intermédiaires.
Lors d’un web scraping, l’erreur 502 peut se produire lorsque le serveur proxy que vous utilisez ne parvient pas à obtenir une réponse appropriée de la part du serveur cible. Pour résoudre ce problème, vérifiez que l’état et la configuration de votre serveur proxy fonctionnent et qu’il peut communiquer avec les serveurs cibles. Vous pouvez surveiller l’utilisation du processeur, de la mémoire et de la bande passante réseau sur votre serveur proxy. Vous pouvez également consulter les journaux d’erreurs du serveur proxy, qui peuvent indiquer s’il y a des problèmes lors du traitement de vos requêtes :
503 : service non disponible
L’erreur 503 Service Unavailable indique que le serveur est occupé et ne peut pas répondre à la requête. Cela peut être dû à une maintenance ou à une surcharge du serveur.
Lors du web scraping, vous rencontrez souvent cette erreur lorsque vous essayez d’accéder à des sites qui ne sont pas accessibles pendant les heures de maintenance ou de pointe. Contrairement à l’erreur 500 qui souligne un problème de serveur, l’erreur 503 indique que le serveur est opérationnel, mais indisponible pour le moment.
Pour éviter cette erreur, vous devez implémenter une stratégie de nouvelle tentative qui utilise une attente (backoff) exponentielle. Les intervalles d’attente devraient augmenter à mesure que les requêtes sont réessayées. Par conséquent, les requêtes ne devraient pas entraîner de saturation du serveur pendant les temps d’arrêt :
504 : expiration de la passerelle
L’erreur 504 Gateway Timeout se produit lorsque le serveur agissant en tant que passerelle ou proxy ne parvient pas à obtenir une réponse du serveur en amont à temps. Cette erreur est un problème de temporisation et une variante de l’erreur 502.
En matière de web scraping, cette erreur se produit souvent lorsque la réponse du serveur cible à votre proxy est trop lente (par exemple en ayant demandé plus de 120 secondes). Pour résoudre ce problème, vous pouvez modifier les paramètres de temporisation de votre scraper afin de respecter des temps d’attente plus longs ou vérifier l’état et la réactivité de votre serveur proxy:
505 : version HTTP non prise en charge
L’erreur 505 HTTP Version Not Supported se produit lorsque le serveur ne reconnaît pas la version du protocole HTTP spécifiée dans la requête. Cela n’est pas courant dans le web scraping, mais cela peut se produire si le serveur cible est configuré pour ne prendre en charge que certaines versions du protocole HTTP. Par exemple, si vos requêtes de scraping arrivent avec une version trop récente ou trop ancienne, le serveur ne les acceptera pas.
Pour éviter cette erreur, vous devez vous assurer que les en-têtes de vos requêtes HTTP indiquent une version acceptable pour le serveur cible, probablement HTTP/1.1 ou HTTP/2, qui sont les versions les plus fréquemment prises en charge :
Conseils rapides pour éviter les erreurs de proxy courantes
Les erreurs de proxy peuvent être frustrantes, mais bon nombre d’entre elles peuvent être contournées en mettant en œuvre quelques stratégies spécifiques dans votre scraper Web.
Réessayer la requête
De nombreux problèmes de proxy sont causés par des problèmes à court terme, tels que de brèves interruptions du réseau ou de petits problèmes de serveur. Une nouvelle tentative de requête peut contourner le problème s’il est naturellement résolu.
Voici comment implémenter les nouvelles tentatives dans votre script de scraping en utilisant la bibliothèque requests de Python et la logique de répétition urllib3 :
import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry
def requests_retry_session(
retries=3,
backoff_factor=0.3,
status_forcelist=(500, 502, 503, 504),
session=None,
):
session = session or requests.Session()
retry = Retry(
total=retries,
read=retries,
connect=retries,
backoff_factor=backoff_factor,
status_forcelist=status_forcelist,
)
adapter = HTTPAdapter(max_retries=retry)
session.mount('http://', adapter)
session.mount('https://', adapter)
return session
s = requests_retry_session()
try:
response = s.get('http://example.com', proxies={"http": "http://proxy_address:port"})
print(response.text)
except requests.exceptions.HTTPError as e:
print('HTTPError:', e)
Ce code définit un mécanisme de nouvelle tentative avec un facteur d’attente, ce qui signifie que si une requête échoue, vous réessayez la même jusqu’à trois fois, en attendant un peu plus longtemps à chaque fois avant la prochaine tentative.
Vérifier les paramètres proxy
Des paramètres proxy incorrects peuvent entraîner de nombreuses erreurs. Par exemple, ces erreurs peuvent se produire si vous saisissez un port proxy, une adresse IP ou des informations d’authentification incorrects. Assurez-vous que vos paramètres sont corrects en fonction des besoins de votre réseau afin que les requêtes puissent atteindre leur destination.
Consulter la documentation et le support technique
Si vous rencontrez un problème lorsque vous utilisez un service ou une bibliothèque proxy, reportez-vous toujours à la documentation officielle comme premier recours. Si vous ne trouvez pas ce que vous recherchez dans la documentation, vérifiez si le service ou la bibliothèque possède une chaîne Slack ou Discord à laquelle vous pouvez vous connecter. Enfin, vous pouvez toujours ouvrir un ticket sur le canal d’assistance ou envoyer un e-mail avec les détails et les questions pour lesquelles vous souhaitez obtenir des réponses.
Conclusion
Cet article vous a expliqué les différents codes d’erreurs de proxys et leur signification, afin de vous aider à identifier chaque erreur et à résoudre les problèmes liés au web scraping. Vous avez également découvert quelques conseils utiles pour éviter que des erreurs courantes ne se produisent.
Si vous rencontrez des problèmes de proxy, pensez à utiliser les services proxy de Bright Data. Nos proxys peuvent contribuer à réduire le nombre d’erreurs et à améliorer l’efficacité du processus de scraping de données. Que vous soyez expert ou novice, la suite d’outils proxy Bright Data peut vous aider à renforcer vos capacités de web scraping.
Aucune carte de crédit requise
