Sommaire de l'article

Vous envoyez une requête POST avec un corps et un en-tête d'autorisation, et le serveur reçoit un GET vide sans aucun en-tête personnalisé. Ça vous dit quelque chose ? Si vous travaillez avec des proxies et des requêtes automatisées, vous finirez tôt ou tard par rencontrer ce comportement. Ce n'est ni un bug de votre code, ni un dysfonctionnement du proxy Proxeon. C'est une mécanique normale des redirections HTTP, prévue par la spécification, qu'il suffit de comprendre et de savoir contrôler.

Dans ce guide, nous allons voir pourquoi la méthode de requête peut changer lors d'une redirection et pourquoi les en-têtes disparaissent. Vous apprendrez à faire la différence entre les codes 301, 302, 307 et 308, vous découvrirez comment différents clients HTTP se comportent par défaut, et vous obtiendrez des exemples concrets pour désactiver les redirections automatiques et les gérer manuellement. Tout ça avec du vrai code, sans blabla.

Introduction : la requête part en POST, mais arrive en GET - qui est responsable ?

Imaginez un problème d'ingénierie. Vous faites une requête POST vers un point d'accès d'authentification via un proxy. Le serveur répond avec un code de redirection et indique une nouvelle adresse. Votre client HTTP suit automatiquement cette adresse. Mais il le fait avec la méthode GET, sans le corps de la requête ni l'en-tête d'autorisation. Résultat : le serveur cible ne reçoit pas ce que vous avez envoyé, et la logique casse.

Qui est responsable ? Officiellement, personne. Ce comportement est ancré dans l'implémentation historique des codes 301 et 302. Autrefois, les navigateurs et les bibliothèques changeaient presque toujours la méthode en GET lorsqu'ils recevaient ces codes. Cela est devenu un standard de fait, et on l'a conservé. Plus tard, pour permettre aux développeurs de conserver la méthode et le corps, les codes 307 et 308 ont été introduits. Nous en reparlerons en détail plus bas.

Ce que vous obtiendrez au final

Après avoir lu ce guide, vous saurez gérer les redirections avec confiance dans n'importe quel client HTTP populaire. Vous pourrez prédire ce qui arrivera à la méthode et au corps de la requête. Vous apprendrez à conserver les en-têtes critiques lors des redirections. Et vous pourrez déboguer des chaînes de redirections complexes qui passent par un proxy.

Pour qui est ce guide

  • Pour les développeurs qui écrivent des scrappers, des intégrations et de l'automatisation via des proxies.
  • Pour les ingénieurs QA qui testent des API et des scénarios web.
  • Pour les DevOps qui configurent le proxyage du trafic.
  • Pour tous ceux qui se sont déjà demandé pourquoi un POST est devenu un GET.

Ce qu'il faut savoir avant de commencer

Une compréhension de base du protocole HTTP : ce qu'est une méthode de requête, les en-têtes, le corps et un code de statut de réponse. Savoir exécuter des commandes dans un terminal. Une connaissance minimale d'un langage comme Python ou JavaScript est un plus. Si ce n'est pas le cas, ne vous inquiétez pas, nous expliquerons les termes clés simplement dans une section dédiée.

Combien de temps cela prendra-t-il ?

Pour une lecture attentive et la reproduction de tous les exemples, comptez environ 60 minutes. Si vous devez résoudre un problème précis, utilisez la table des matières et allez directement à la section concernée.

Préparation : outils et accès

Avant de travailler avec les exemples, préparez votre environnement de travail. Cela prendra un peu de temps, mais ensuite tout se passera bien.

Outils nécessaires

  1. Installez curl version 7.88 ou plus récente. Vérifiez avec la commande curl --version dans le terminal.
  2. Installez Python version 3.10 ou plus récente. Vérifiez avec la commande python --version.
  3. Installez les bibliothèques Python : exécutez pip install requests httpx.
  4. Installez Node.js version 20 ou plus récente, si vous prévoyez de tester axios et fetch. Vérifiez avec la commande node --version.
  5. Installez axios via npm install axios dans un dossier de test.

Accès au proxy

Pour la pratique, vous aurez besoin de proxies Proxeon fonctionnels. Préparez les informations de connexion : adresse du serveur, port, nom d'utilisateur et mot de passe. Gardez-les dans un endroit sûr. Nous les intégrerons dans les exemples de code.

Conseil : Ne stockez jamais vos identifiants de proxy directement dans le code. Utilisez des variables d'environnement. Par exemple, dans le terminal, définissez export PROXY_URL=http://user:pass@host:port, puis lisez cette valeur dans le code. Ainsi, vous n'enverrez pas accidentellement des secrets dans un dépôt.

Configuration système

Tout ordinateur moderne avec Windows 10 ou plus, macOS 12 ou plus, ou une distribution Linux récente convient. Il n'y a pas d'exigences matérielles particulières : les requêtes HTTP ne chargent pas le système.

⚠️ Attention : Si vous testez sur un serveur de production, créez d'abord une branche de code de test ou un script de test séparé. Ne testez pas la logique des redirections directement en production - changer le comportement des redirections peut casser l'authentification et envoyer des requêtes au mauvais endroit.

✅ Vérification : À ce stade, les commandes de vérification des versions de curl, Python et Node.js doivent fonctionner, et les identifiants du proxy Proxeon doivent être stockés dans une variable d'environnement.

Les bases en termes simples

Pour que la suite soit claire, passons en revue les termes clés. Même si vous les connaissez, un petit rafraîchissement ne fait pas de mal.

Qu'est-ce qu'une redirection ?

Une redirection est une réponse du serveur qui dit au client : la ressource que tu cherches n'est pas ici, va à une autre adresse. Le serveur renvoie un code de statut de la famille 3xx et un en-tête Location avec la nouvelle adresse. Le client lit cet en-tête et envoie une nouvelle requête vers cette adresse.

Qu'est-ce que la méthode de requête et le corps ?

La méthode est le type d'action. GET demande des données, POST envoie des données au serveur, PUT met à jour, DELETE supprime. Le corps de la requête est la charge utile que vous envoyez avec POST ou PUT. Par exemple, du JSON avec un nom d'utilisateur et un mot de passe lors d'une authentification.

Qu'est-ce que les en-têtes ?

Les en-têtes sont les métadonnées de la requête. Ils transmettent des informations supplémentaires : le format des données (Content-Type), l'authentification (Authorization), l'agent utilisateur (User-Agent), vos propres champs personnalisés. Lors d'une redirection, certains en-têtes peuvent être conservés, d'autres perdus. C'est souvent ce qui casse la logique.

Qu'est-ce que le suivi automatique ?

Le suivi automatique, c'est quand votre client HTTP suit lui-même, sans votre intervention, l'adresse de l'en-tête Location. La plupart des clients le font par défaut. C'est pratique, mais risqué : vous perdez le contrôle sur ce qui se passe avec la méthode, le corps et les en-têtes entre les étapes.

Où le proxy intervient-il ?

Le proxy Proxeon se situe entre votre client et le serveur cible. Il transmet votre requête et renvoie la réponse. Lors d'une redirection, le proxy se contente de transmettre le code de statut et l'en-tête Location. La décision de suivre la redirection revient à votre client. Un point important : si vous utilisez un pool de proxies avec rotation, les différentes étapes de la chaîne de redirections peuvent passer par des IP différentes. Nous y reviendrons en détail.

Conseil : Retenez une règle simple. Le proxy ne change pas la méthode de requête lors d'une redirection. C'est votre client HTTP qui change la méthode selon les règles de traitement du code de statut. Il faut donc chercher la cause dans les paramètres du client, pas dans le proxy.

Étape 1 : Comprendre les quatre codes - 301 et 302 contre 307 et 308

Objectif : apprendre à déterminer sans erreur ce qui arrivera à la méthode et au corps de la requête pour chacun des quatre codes de redirection.

C'est la base de tout le guide. Si vous assimilez la différence entre ces codes, la moitié des problèmes de redirection disparaîtra d'elle-même.

Code 301 - Redirection permanente

Signifie que la ressource a définitivement changé d'adresse. Historiquement, à la réception d'un 301, les clients changent la méthode POST en GET et jettent le corps de la requête. Officiellement, la spécification ne l'exige pas, mais c'est ce qui se fait en pratique, et presque tous les clients le font pour des raisons de compatibilité.

Code 302 - Redirection temporaire

Signifie que la ressource est temporairement disponible à une autre adresse. Le comportement est similaire au 301 : en pratique, POST devient GET et le corps est perdu. C'est ce code 302 qui est le plus souvent responsable de la situation décrite en introduction.

Code 307 - Redirection temporaire avec conservation de la méthode

Ce code a été introduit spécialement pour résoudre le problème du changement de méthode. Avec un 307, le client doit conserver la méthode et le corps d'origine. Vous avez envoyé un POST ? Ce sera un POST. Vous avez envoyé un corps ? Il sera transmis. C'est l'équivalent temporaire du 302, mais sans les surprises sur la méthode.

Code 308 - Redirection permanente avec conservation de la méthode

Équivalent permanent du 301, mais avec conservation de la méthode et du corps. Vous avez envoyé un POST ? Ce sera un POST. C'est le code le plus prévisible pour rediriger des requêtes POST.

Tableau récapitulatif des comportements

Voici une description verbale du tableau pour que vous ayez une vision claire.

  • 301 : permanent. En pratique, POST devient GET. Le corps est jeté. GET reste GET.
  • 302 : temporaire. En pratique, POST devient GET. Le corps est jeté. GET reste GET.
  • 307 : temporaire. La méthode est entièrement conservée. Le corps est conservé. POST reste POST.
  • 308 : permanent. La méthode est entièrement conservée. Le corps est conservé. POST reste POST.

⚠️ Attention : Ne comptez pas sur le fait que tous les serveurs suivent strictement la spécification. Certains systèmes anciens renvoient un 302 là où logiquement un 307 serait nécessaire, en attendant que la méthode soit conservée. Vérifiez toujours le comportement réel, pas seulement le code. Testez sur un vrai point d'accès.

Conseil : Si vous développez votre propre serveur et que vous voulez que les requêtes POST restent des POST après une redirection, utilisez les codes 307 ou 308. Cela évitera à vos clients des surprises désagréables et des heures de débogage.

✅ Vérification : Vous pouvez, en voyant le code de réponse, dire immédiatement si la méthode et le corps seront conservés. Pour 307 et 308, oui. Pour 301 et 302, en pratique, non.

Étape 2 : Ce qui se perd lors d'une redirection - Authorization, en-têtes personnalisés, cookies

Objectif : comprendre quelles données disparaissent lors d'une redirection et pourquoi, afin de prévoir leur conservation.

Le changement de méthode n'est pas le seul problème. Même avec les codes 307 et 308, où la méthode est conservée, une partie des en-têtes peut disparaître. Passons en revue trois pertes majeures.

Perte de l'en-tête Authorization lors d'un changement de domaine

C'est le problème le plus courant et le plus sournois. Pour des raisons de sécurité, la plupart des clients HTTP suppriment l'en-tête Authorization lors d'une redirection vers un autre domaine. La logique est simple : si vous vous authentifiez sur le site A, votre jeton secret ne doit pas automatiquement partir vers le site B vers lequel vous êtes redirigé. Sinon, un attaquant pourrait configurer une redirection et soutirer vos identifiants.

Résultat : vous envoyez une requête avec un jeton valide, le client suit la redirection vers un autre domaine, mais sans Authorization. Le serveur cible répond que vous n'êtes pas authentifié. Logique, mais pas évident.

Conseil : Si vous devez vraiment transmettre l'autorisation à un autre domaine, faites-le consciemment et manuellement. Désactivez le suivi automatique, vérifiez où mène exactement Location, assurez-vous que c'est une adresse de confiance, puis ajoutez l'en-tête Authorization à la nouvelle requête de vos propres mains.

Perte des en-têtes personnalisés

Vos propres en-têtes - par exemple, des champs de service comme X-Request-Id ou X-Client-Version - lors d'une redirection automatique, se comportent différemment selon le client. Certaines bibliothèques les transmettent, d'autres les effacent. On ne peut pas s'y fier. Si un en-tête est critique pour la logique, contrôlez sa transmission manuellement.

Perte des cookies avec des indicateurs (flags)

Les cookies ont des indicateurs qui limitent leur envoi. L'indicateur Secure autorise l'envoi uniquement via une connexion sécurisée. L'indicateur Domain limite l'ensemble des domaines vers lesquels le cookie est envoyé. L'indicateur SameSite régule l'envoi lors des passages entre sites. Si la redirection vous amène sur un domaine ou un protocole qui ne correspond pas aux indicateurs du cookie, ce cookie ne sera simplement pas envoyé.

Par exemple, un cookie avec l'indicateur Secure ne partira pas si la redirection mène vers une adresse non sécurisée. Un cookie avec une restriction de domaine n'ira pas vers un autre domaine. C'est un comportement correct du point de vue de la sécurité, mais il faut en tenir compte.

⚠️ Attention : N'essayez jamais de forcer la suppression des indicateurs de sécurité des cookies d'autrui ou de transmettre Authorization vers des domaines non fiables par commodité. Ces mécanismes protègent vos identifiants. Ne les contournez que sur une infrastructure que vous contrôlez entièrement, et en comprenant parfaitement les conséquences.

✅ Vérification : Vous comprenez les trois types de pertes lors d'une redirection : l'en-tête Authorization sur un autre domaine, les en-têtes personnalisés, les cookies avec des indicateurs restrictifs. Vous savez que chacun d'eux ne peut être restauré que par un traitement manuel conscient.

Étape 3 : Comportement par défaut dans différents clients

Objectif : savoir comment se comporte chaque client HTTP populaire pour ne pas être surpris par les différences.

Le piège principal, c'est que tous les clients n'ont pas le même comportement par défaut. Passons en revue les cinq plus courants.

curl

Par défaut, curl ne suit pas les redirections du tout. Il se contente d'afficher la réponse avec le code 3xx et l'en-tête Location. Pour activer le suivi automatique, il faut ajouter explicitement l'option -L. Cela rend curl très prévisible : vous savez toujours que sans cette option, aucun suivi caché n'aura lieu.

Exemple de requête sans suivi :

curl -i -x $PROXY_URL https://example.com/redirect

L'option -i affiche les en-têtes de réponse, l'option -x définit le proxy. Vous verrez le code et Location, mais aucun suivi n'aura lieu.

requests (Python)

La bibliothèque requests suit automatiquement les redirections par défaut. Pour les codes 301, 302 et 303, elle change la méthode POST en GET. Pour 307 et 308, elle conserve la méthode. Vous pouvez désactiver le suivi avec le paramètre allow_redirects=False.

httpx (Python)

Fait intéressant : httpx ne suit pas les redirections par défaut, contrairement à requests. C'est un choix délibéré pour que le développeur prenne explicitement la décision. Pour activer le suivi, passez follow_redirects=True. Ce comportement est plus proche de la philosophie de curl.

axios (JavaScript, Node.js)

Sous Node.js, axios suit automatiquement les redirections par défaut. Vous pouvez limiter ou désactiver cela avec le paramètre maxRedirects. Si vous définissez maxRedirects: 0, le suivi automatique est désactivé et axios renverra une erreur ou une réponse avec le code de redirection selon la configuration.

fetch (navigateur et Node.js)

Le fetch standard suit automatiquement les redirections par défaut. Vous pouvez contrôler cela avec le paramètre redirect, qui accepte trois valeurs : follow pour suivre, manual pour ne pas suivre et renvoyer une réponse opaque, error pour considérer la redirection comme une erreur.

Conseil : Retenez deux groupes. curl et httpx ne suivent pas par défaut - vous décidez. requests, axios et fetch suivent par défaut. Si vous transférez du code entre ces outils, vérifiez toujours le paramètre de redirection, sinon la logique se cassera silencieusement.

⚠️ Attention : Le comportement par défaut différent est la cause numéro un de bugs mystérieux lors de la réécriture de scripts d'un client à un autre. Un script avec requests fonctionnait, vous l'avez transféré sur httpx, et soudain, au lieu de la réponse finale, vous obtenez un code 302. La raison : httpx ne suit pas automatiquement. Indiquez toujours explicitement le paramètre de redirection.

✅ Vérification : Vous pouvez nommer de mémoire le comportement par défaut pour curl, requests, httpx, axios et fetch, et vous connaissez le paramètre pour contrôler les redirections dans chacun.

Étape 4 : Gestion manuelle des redirections - quand c'est la seule bonne solution

Objectif : apprendre à désactiver le suivi automatique et à traiter chaque étape de la redirection manuellement, en contrôlant totalement la méthode, le corps et les en-têtes.

Le suivi automatique est pratique, mais dans trois situations, il est nocif et un contrôle manuel est nécessaire :

  1. Lorsque vous devez conserver Authorization lors d'une redirection vers un autre domaine.
  2. Lorsqu'il est important de savoir précisément par quel proxy et quelle IP chaque étape de la chaîne est passée.
  3. Lorsque le serveur répond avec un 302 là où logiquement un 307 serait nécessaire, et que vous voulez conserver manuellement la méthode POST.

Désactivation du suivi automatique : curl

Avec curl, c'est simple : n'ajoutez pas l'option -L. Le client affichera la première réponse. Ensuite, vous prenez vous-même Location et faites une nouvelle requête :

curl -i -x $PROXY_URL "https://example.com/login"

Lisez l'en-tête Location dans la sortie, puis effectuez la requête suivante manuellement, en ajoutant les en-têtes nécessaires :

curl -i -x $PROXY_URL -H "Authorization: Bearer TOKEN" "https://example.com/next"

Désactivation du suivi automatique : requests

Ici, utilisez le paramètre allow_redirects=False et traitez la chaîne dans une boucle :

import os, requests; proxies = {"http": os.environ["PROXY_URL"], "https": os.environ["PROXY_URL"]}; url = "https://example.com/login"; method = "POST"; body = {"user": "a", "pass": "b"}; headers = {"Authorization": "Bearer TOKEN"}; 
for _ in range(5): 
r = requests.request(method, url, json=body, headers=headers, proxies=proxies, allow_redirects=False); 
if r.status_code not in (301, 302, 303, 307, 308): break; 
loc = r.headers["Location"]; 
if r.status_code in (301, 302, 303): method = "GET"; body = None; 
url = loc

Notez que dans cette boucle, vous décidez vous-même de changer de méthode ou non, et vous décidez de conserver l'en-tête Authorization ou non. C'est là toute la force du traitement manuel.

Désactivation du suivi automatique : httpx

Comme httpx ne suit pas par défaut, il suffit de ne pas activer follow_redirects. La logique de la boucle est identique à requests : vérifier le code, lire Location, prendre des décisions sur la méthode et les en-têtes, faire la requête suivante.

Désactivation du suivi automatique : axios

Avec axios, définissez maxRedirects: 0. À la réception d'un code de redirection, axios sous Node.js lèvera une erreur, dans laquelle l'objet response contiendra le statut et les en-têtes. À partir de l'en-tête Location, vous prenez la nouvelle adresse et vous effectuez la requête suivante vous-même.

Désactivation du suivi automatique : fetch

Avec fetch, passez redirect: "manual". Ainsi, fetch ne suivra pas et renverra une réponse à partir de laquelle vous lirez les données nécessaires pour l'étape suivante.

Conseil : Lors du traitement manuel, journalisez toujours à chaque étape quatre éléments : l'URL d'origine, le code reçu, la valeur de Location et la méthode de la requête suivante. Cela transformera une chaîne incompréhensible en une séquence transparente, facile à lire et à déboguer.

⚠️ Attention : Avec le traitement manuel, vous êtes responsable de la sécurité. Avant de transférer Authorization vers une nouvelle adresse depuis Location, vérifiez que le domaine appartient à une infrastructure de confiance. Copier aveuglément des secrets vers une adresse quelconque depuis Location est une grave vulnérabilité.

✅ Vérification : Vous avez un exemple fonctionnel de boucle de traitement manuel dans au moins un client, qui traverse correctement une chaîne de redirections et conserve les en-têtes nécessaires uniquement pour les domaines de confiance.

Étape 5 : Limiter la profondeur et se protéger contre les boucles

Objectif : protéger votre code contre les redirections infinies et éviter que la boucle de redirections ne fige votre application.

Parfois, les serveurs sont mal configurés, et l'adresse A mène à l'adresse B, qui mène à A. Si votre client suit sans limite, il bouclera indéfiniment. Avec le traitement manuel, le danger est le même : une boucle sans compteur tournera éternellement.

Limiter le nombre de redirections

Définissez toujours une profondeur maximale. Une valeur raisonnable est de cinq à dix redirections. Au-delà, c'est rare dans les scénarios normaux.

  • Dans curl : l'option --max-redirs 10 avec -L.
  • Dans requests : la bibliothèque limite elle-même la profondeur, mais dans une boucle manuelle, utilisez range(10).
  • Dans httpx : le paramètre max_redirects lorsque le suivi est activé.
  • Dans axios : le paramètre maxRedirects avec le nombre souhaité.
  • Dans fetch : comptez les redirections vous-même dans la boucle.

Protection contre les boucles en suivant les adresses visitées

Un moyen fiable : stockez l'ensemble des URL déjà visitées. Avant chaque redirection, vérifiez si vous êtes déjà allé sur cette adresse. Si c'est le cas, interrompez la chaîne avec une erreur. Cela détecte même les boucles complexes avec plusieurs adresses.

seen = set(); 
while url and url not in seen: 
seen.add(url); 
r = requests.request(method, url, headers=headers, proxies=proxies, allow_redirects=False); 
if r.status_code not in (301,302,303,307,308): break; 
url = r.headers["Location"]

Conseil : Combinez les deux techniques : à la fois une limite stricte en nombre et l'ensemble des adresses visitées. La limite protège contre les longues chaînes, l'ensemble contre les boucles. Ensemble, ils offrent une protection complète.

✅ Vérification : Votre code se termine toujours sur n'importe quelle chaîne de redirections, même si le serveur crée une boucle infinie. Il atteint soit la réponse finale, soit s'interrompt avec une erreur claire indiquant un dépassement de profondeur ou une boucle détectée.

Étape 6 : Redirections et changement d'IP - pourquoi la chaîne passe par un autre proxy

Objectif : comprendre comment la rotation de proxies interagit avec les redirections et éviter que les étapes de la chaîne ne passent par des IP différentes.

C'est un point subtil et souvent sous-estimé. Si vous utilisez un pool de proxies Proxeon avec rotation d'IP, il est essentiel de comprendre à quel niveau le changement d'adresse se produit.

Pourquoi les étapes peuvent passer par des IP différentes

Imaginez que votre rotation est configurée pour changer d'IP à chaque nouvelle connexion. Lors d'un suivi automatique, le client peut ouvrir une nouvelle connexion pour l'étape suivante de la redirection. Si, entre les étapes, la rotation fournit une nouvelle IP, la première requête partira d'une adresse, et la redirection via Location d'une autre. Pour de nombreux serveurs, cela semble suspect : l'authentification a été commencée par un client, et poursuivie comme si c'était un autre.

Ce qui casse alors

  • Les sessions liées à une IP se rompent. Le serveur voit que la suite vient d'une autre adresse et réinitialise la session.
  • Les cookies émis pour une session spécifique ne sont plus acceptés.
  • La logique qui attend une source unique dans la chaîne devient instable.

Comment garder une même session sur une même IP

La clé est de fixer l'IP pendant toute la chaîne. Proxeon prend en charge le mode session persistante (sticky session), où la même IP est conservée pendant une période donnée. Utilisez-le pour les scénarios où l'intégrité de la chaîne de redirections est importante.

  1. Choisissez dans les paramètres de connexion le mode session persistante plutôt que la rotation à chaque requête.
  2. Définissez un temps de maintien de l'IP avec une marge pour toute la chaîne de redirections.
  3. Dans le code, utilisez une seule session client pour toutes les étapes : dans requests, c'est l'objet requests.Session(), dans httpx, httpx.Client().
  4. Assurez-vous de réutiliser la connexion et non d'en créer une nouvelle à chaque étape.

Conseil : Pour l'intégrité de la chaîne de redirections, créez toujours un seul objet de session client et faites passer toutes les étapes par lui. Cela réutilise la connexion, conserve les cookies entre les requêtes et réduit le risque de changer d'IP au milieu de la chaîne.

⚠️ Attention : Ne confondez pas session persistante et maintien infini de l'IP. Définissez un temps de maintien raisonnable, juste pour la durée de l'opération. Rappelez-vous que tout travail avec un proxy doit se faire dans le respect de la législation et des règles des ressources avec lesquelles vous interagissez.

✅ Vérification : Toute la chaîne de redirections passe par la même IP, la session ne se rompt pas, les cookies sont acceptés à chaque étape. Vous pouvez le vérifier en demandant à chaque étape un service qui affiche votre IP actuelle et en vous assurant qu'elle ne change pas.

Étape 7 : Débogage - comment voir toute la chaîne et les codes étape par étape

Objectif : obtenir une image complète de la chaîne de redirections pour savoir précisément où la méthode ou un en-tête se perd.

Déboguer à l'aveugle est la pire chose à faire avec les redirections. Voici des outils qui rendent la chaîne visible.

Journal complet dans curl

L'option -v active le mode verbeux. Vous verrez chaque requête, chaque réponse, tous les en-têtes et tous les suivis. Avec l'option -L, curl affichera toute la chaîne d'un coup.

curl -v -L --max-redirs 10 -x $PROXY_URL "https://example.com/login"

Lisez la sortie de haut en bas. Les lignes commençant par un symbole supérieur (>) sont ce qui part vers le serveur. Les lignes avec un symbole inférieur (<) sont ce qui revient en réponse. C'est ainsi que vous verrez à quelle étape un en-tête a disparu.

Historique des redirections dans requests

Si vous laissez le suivi automatique activé, la réponse finale aura un attribut history - une liste de toutes les réponses intermédiaires. Parcourez-la et affichez le code et l'URL de chaque étape :

r = requests.post(url, json=body, proxies=proxies); 
for h in r.history: print(h.status_code, h.url); 
print("final", r.status_code, r.url)

Historique des redirections dans httpx

Lorsque le suivi automatique est activé, la réponse httpx a aussi une propriété history. La logique est la même : parcourez et affichez le code et l'URL de chaque réponse intermédiaire.

Débogage avec axios et fetch

Avec axios, lors du traitement manuel, journalisez chaque réponse dans la boucle vous-même. Avec fetch en mode manual, affichez le statut et l'en-tête Location à chaque étape. Il n'y a pas de liste intégrée d'historique ici, donc la journalisation manuelle est votre principal outil.

Conseil : Adoptez un format de journal unique pour une étape : numéro d'étape, méthode, URL, code de réponse, Location, présence d'Authorization. Un tel journal tabulaire montre instantanément où la méthode est devenue GET ou où le jeton a disparu. Cela fait gagner des heures de débogage.

Ce qu'il faut chercher dans les journaux

  • Le moment où la méthode de la requête sortante devient GET au lieu de POST. C'est un signe d'un code 301, 302 ou 303.
  • L'étape où l'en-tête Authorization disparaît. C'est généralement un passage vers un autre domaine.
  • Le changement de domaine ou de protocole dans la valeur de Location - c'est là que les cookies avec des indicateurs sont perdus.
  • Des adresses répétées - signe d'une boucle.

✅ Vérification : Vous pouvez afficher la chaîne complète des redirections avec les codes et les URL pour n'importe quel client et identifier précisément l'étape où la méthode a changé ou où un en-tête a disparu.

Vérification du résultat : liste de contrôle

Parcourez cette liste. Si tous les points sont validés, vous contrôlez entièrement les redirections.

  1. Vous connaissez le comportement de la méthode et du corps pour les codes 301, 302, 307 et 308.
  2. Vous comprenez pourquoi Authorization disparaît lors d'un changement de domaine.
  3. Vous connaissez le comportement par défaut de curl, requests, httpx, axios et fetch.
  4. Vous avez un exemple fonctionnel de désactivation du suivi automatique.
  5. Vous avez une boucle de traitement manuel fonctionnelle.
  6. Votre code est protégé contre les boucles infinies grâce à une limite et à un ensemble d'adresses visitées.
  7. Vous utilisez la session persistante Proxeon pour l'intégrité de la chaîne lorsque c'est nécessaire.
  8. Vous savez afficher la chaîne complète des redirections dans les journaux.

Comment tester

Prenez un point d'accès de test qui répond avec un code 302 à une requête POST. Passez-le via le suivi automatique et vérifiez que la méthode devient GET. Ensuite, passez-le via le traitement manuel en conservant la méthode et vérifiez que POST atteint l'adresse finale. La différence de comportement prouvera que vous contrôlez tout.

✅ Vérification : Les deux scénarios - suivi automatique et traitement manuel - donnent un résultat prévisible et explicable, pas aléatoire.

Erreurs courantes et solutions

Passons en revue les pièges les plus fréquents et comment les éviter.

Erreur 1 : POST devient GET

Cause : le serveur a renvoyé un code 301 ou 302, et le client a changé de méthode selon la règle historique. Solution : si vous contrôlez le serveur, renvoyez un 307 ou un 308. Sinon, désactivez le suivi automatique et répétez la requête avec la bonne méthode manuellement.

Erreur 2 : l'en-tête Authorization a disparu

Cause : la redirection a mené vers un autre domaine, le client a supprimé le secret pour des raisons de sécurité. Solution : vérifiez le domaine de Location, et s'il est de confiance, ajoutez Authorization à la requête suivante manuellement.

Erreur 3 : le script fonctionnait avec requests, mais a cassé avec httpx

Cause : httpx ne suit pas les redirections par défaut, contrairement à requests. Solution : définissez explicitement follow_redirects=True dans httpx ou, inversement, optez systématiquement pour le traitement manuel pour plus de cohérence.

Erreur 4 : l'application a gelé sur une chaîne

Cause : une boucle de redirections infinie sans limite de profondeur. Solution : ajoutez une limite de redirections et un ensemble d'adresses visitées, comme indiqué à l'étape 5.

Erreur 5 : la session se réinitialise au milieu de la chaîne

Cause : les étapes de la chaîne sont passées par des IP différentes à cause de la rotation du proxy. Solution : activez la session persistante Proxeon et utilisez un seul objet de session client pour toutes les étapes.

Erreur 6 : le cookie n'est pas envoyé après une redirection

Cause : un indicateur Secure, Domain ou SameSite ne correspond pas à la nouvelle adresse. Solution : vérifiez le protocole et le domaine dans Location et assurez-vous qu'ils correspondent aux indicateurs du cookie. Ne retirez pas les indicateurs de sécurité par commodité.

Erreur 7 : curl ne suit pas la redirection

Cause : vous avez oublié l'option -L. Solution : ajoutez -L pour le suivi automatique, ou laissez sans pour un contrôle manuel - selon la tâche.

Fonctionnalités supplémentaires et optimisation

Une fois les bases acquises, il est bon de mettre de l'ordre et d'améliorer la fiabilité.

Module unique de traitement des redirections

Ne dispersez pas la logique dans le code. Regroupez le traitement de la chaîne dans une seule fonction avec des paramètres : liste des domaines de confiance, profondeur maximale, ensemble de codes pour conserver la méthode. Ainsi, le comportement sera uniforme dans tout le projet.

Liste blanche de domaines pour Authorization

Créez une liste explicite de domaines vers lesquels il est autorisé de transmettre Authorization lors d'une redirection. Tout ce qui est hors liste ne reçoit jamais le secret. Cela rend la sécurité gérable, pas aléatoire.

Métriques des chaînes

Collectez des statistiques : longueur moyenne des chaînes, proportion de requêtes avec redirections, codes les plus fréquents. Une augmentation anormale de la longueur des chaînes est un signal précoce de problèmes côté serveur cible.

Conseil : Configurez une alerte si la chaîne dépasse trois redirections. La plupart des scénarios corrects nécessitent une ou deux redirections. Une augmentation soudaine mérite une enquête sur ce qui a changé sur la ressource cible.

FAQ : questions fréquentes sur la gestion des redirections

Pourquoi POST devient GET si je n'ai rien changé ?

Parce que le serveur a renvoyé un code 301 ou 302, et votre client a changé la méthode en GET selon la règle historique. Pour éviter cela, il faut un code 307 ou 308, ou un traitement manuel.

Le proxy change-t-il la méthode de requête lors d'une redirection ?

Non. Proxeon et tout proxy correct se contentent de transmettre le statut et Location. La décision de changer de méthode revient à votre client HTTP. Cherchez la cause dans les paramètres du client.

Comment conserver Authorization lors d'un passage vers un autre domaine ?

Uniquement manuellement. Désactivez le suivi automatique, vérifiez le domaine de Location, assurez-vous qu'il est de confiance, puis ajoutez l'en-tête Authorization à la requête suivante vous-même.

Quel code est préférable pour rediriger un POST ?

Le code 307 pour une redirection temporaire et le 308 pour une redirection permanente. Les deux conservent la méthode et le corps de la requête, évitant ainsi les surprises aux clients.

Pourquoi le même script se comporte différemment avec requests et httpx ?

Parce que requests suit les redirections par défaut, tandis que httpx ne les suit pas. Définissez explicitement le paramètre de suivi pour que les comportements concordent.

Comment se protéger contre une boucle infinie de redirections ?

Définissez une limite stricte de redirections et tenez un ensemble des adresses déjà visitées. Si une adresse se répète ou si la limite est dépassée, interrompez la chaîne avec une erreur.

Pourquoi la session se rompt au milieu de la chaîne de redirections ?

Probablement parce que les étapes sont passées par des IP différentes à cause de la rotation. Activez la session persistante Proxeon et utilisez un seul objet de session client pour toutes les étapes.

Pourquoi le cookie n'est-il pas envoyé après le passage ?

À cause d'une non-correspondance des indicateurs Secure, Domain ou SameSite avec la nouvelle adresse. Vérifiez le protocole et le domaine dans Location. Les indicateurs de sécurité ne doivent pas être retirés.

Comment voir toute la chaîne de redirections ?

Avec curl, utilisez -v -L. Avec requests et httpx, regardez l'attribut history de la réponse finale. Avec axios et fetch, journalisez chaque étape manuellement.

Puis-je interdire complètement les redirections ?

Oui. Dans curl, n'ajoutez pas -L ; dans requests, définissez allow_redirects=False ; dans httpx, n'activez pas follow_redirects ; dans axios, mettez maxRedirects: 0 ; dans fetch, indiquez redirect: "manual".

Conclusion

Vous avez maintenant une vision complète et pratique de la gestion des redirections via un proxy. Vous avez compris pourquoi POST devient GET et vous savez que ce n'est pas le proxy qui en est responsable, mais les règles historiques de traitement des codes 301 et 302. Vous comprenez la différence entre 301, 302, 307 et 308 et vous savez choisir le bon code. Vous savez quelles données se perdent lors d'une redirection : Authorization sur un autre domaine, en-têtes personnalisés, cookies avec des indicateurs de sécurité.

Vous avez étudié le comportement par défaut de curl, requests, httpx, axios et fetch et vous ne serez plus surpris par les différences lors d'un transfert de code. Vous avez des exemples fonctionnels pour désactiver le suivi automatique et traiter manuellement la chaîne avec un contrôle total de la méthode et des en-têtes. Vous savez vous protéger contre les boucles et maintenir une même session sur une même IP grâce à la session persistante Proxeon. Enfin, vous savez déboguer les chaînes et voir chaque étape.

Et maintenant ? Créez un module unique de traitement des redirections avec une liste blanche de domaines pour Authorization et une profondeur configurable. Ajoutez des métriques sur la longueur des chaînes. Testez vos scénarios réels avec le traitement manuel et comparez avec le suivi automatique - vous découvrirez ainsi les endroits cachés où des données se perdaient.

Continuez à approfondir la pile réseau : comprenez mieux le cycle de vie des cookies, les subtilités des connexions TLS et la réutilisation des connexions. Chacune de ces compétences rendra votre travail avec le proxy Proxeon encore plus fiable et prévisible. Bonne ingénierie et que vos chaînes de requêtes soient propres et transparentes.