Si une requête directe atteint une redirection et que l'échange suivant échoue sur un proxy, examinez la transition. Requests reconstruit les réglages liés au proxy pour les redirections et peut de nouveau consulter l'environnement lorsque la Session lui fait confiance.

Valeur de mappageCe qui se produit lors de la fusion
NoneLa clé est supprimée, laissant une entrée manquante qu'une passe ultérieure peut remplir depuis l'environnement.
Une chaîne videLa valeur explicite subsiste ; elle peut préserver l'intention de routage direct pour ce schéma.

Pour une Session existante, fournissez les schémas de destination impliqués dans l'opération directe :

response = session.get(
    'https://example.com/start',
    proxies={'http': '', 'https': ''},
    timeout=15,
)

Vérifiez les mappages supplémentaires propres à l'hôte et les adaptateurs personnalisés si l'application les fournit. Cette entrée de routage ne supplante pas toutes les politiques possibles que ces composants appliquent.

Conservez chaque URL dans le diagnostic

Notez l'URL d'origine, chaque emplacement de redirection, le statut de la réponse et l'étape qui échoue. Le passage de HTTP à HTTPS change la clé de schéma concernée ; un nouvel hôte peut sortir de la règle de contournement du premier hôte. Un rapport qui ne contient que l'URL initiale masque les deux transitions.

Observer une réponse avec le suivi des redirections désactivé peut révéler la frontière. Examinez son emplacement comme une donnée avant de décider de la demander ; n'envoyez pas indistinctement les identifiants d'origine vers une nouvelle destination.

Une Session dédiée avec la découverte d'environnement désactivée est une autre option lorsque l'application possède délibérément toutes les entrées de routage et de confiance. Cela affecte aussi la découverte automatique des identifiants et des CA, choisissez-la donc comme politique d'application plutôt que comme réparation de routine d'une redirection.

Articles similaires