Il existe deux façons d’effectuer une requête HTTP en JavaScript, qui font l’objet d’un débat sans fin, et ce débat porte généralement sur des aspects secondaires.
La taille du bundle, l’élégance de la syntaxe, la justification d’une dépendance… Ce sont là des questions de préférence, et les avis divergent entre personnes raisonnables. Une différence, cependant, n’est pas une question de préférence, et elle génère de véritables bogues dans le code de production : fetch ne rejette pas sa promesse lorsque le serveur renvoie un statut d’erreur. Un code 404 est résolu. Un code 500 est résolu. Votre .catch() ne s’exécute jamais et le code continue comme si tout avait fonctionné.
Il s’agit d’un comportement documenté plutôt que d’une bizarrerie, et c’est ce qu’il faut comprendre avant toute autre chose.
Nous sommes Geonode et nous vendons des proxys ; voici donc une remarque pertinente : il existe une différence réelle et peu documentée entre ces deux éléments concernant la prise en charge des proxys dans Node, et cela prend régulièrement les utilisateurs au dépourvu. L’fetche native de Node ne détecte pas les variables d’environnement de proxy standard, ce qui surprend presque tous ceux qui s’attendent à ce qu’elle se comporte comme curl. Ce sujet fait l’objet d’une section à part entière, et si vous ne faites pas transiter vos requêtes par un proxy, vous pouvez l’ignorer complètement — ce que la plupart des gens devraient faire.
Une petite remarque d’ordre pratique, car elle concerne tous ceux qui suivent d’anciens liens : la documentation d’Axios a été déplacée. axios-http.com redirige désormais vers axios.rest. Les signets et les réponses de Stack Overflow pointant vers l’ancien domaine fonctionnent toujours grâce à la redirection, mais l’emplacement canonique a changé.
Tout ce qui suit concernant le comportement provient de MDN et de la documentation d’Axios elle-même, et non de la mémoire de quiconque.
La différence qui entraîne de véritables bugs
Commencez par là, car c’est la seule différence qui ne relève pas d’une question de goût.
Ce qu'en dit MDN
Extrait direct de la documentation :
« Une promesse de type fetch()
n'échoue que lorsque la requête échoue, par exemple en raison d'une URL de requête mal formée ou d'une erreur réseau. Une promesse fetch()
ne rejette pas si le serveur répond avec des codes d’état HTTP indiquant des erreurs (404
, 504
, etc.). Au lieu de cela, un gestionnaire then()
doit vérifier les propriétés Response.ok
et/ou Response.status
. »
L’accent mis sur ne est celui de MDN.
Ce que cela signifie en pratique
// Looks correct. Is not.
try {
const res = await fetch('/api/user/999');
const user = await res.json();
showUser(user); // runs on a 404
} catch (err) {
showError(err); // never runs on a 404
}
Le serveur a renvoyé un code 404 avec un corps d’erreur. fetch
s’est résolu sans problème. res.json()
a analysé l’objet d’erreur. showUser
a reçu un élément qui n’est pas un utilisateur, et l’échec se manifeste plus tard, ailleurs, sous la forme d’une erreur déroutante concernant une propriété non définie.
La version correcte :
try {
const res = await fetch('/api/user/999');
if (!res.ok) {
throw new Error(`HTTP ${res.status}`);
}
const user = await res.json();
showUser(user);
} catch (err) {
showError(err);
}
Trois lignes supplémentaires, qui sont obligatoires dans chaque requête que vous écrivez.
Comment se comporte Axios
Par défaut, Axios rejette les codes d’état hors de la plage 2xx. Le code équivalent ne nécessite aucune vérification du statut :
try {
const { data } = await axios.get('/api/user/999');
showUser(data);
} catch (err) {
showError(err); // runs on a 404
}
Quel comportement est correct ?
Les deux sont défendables, et le désaccord est d’ordre philosophique.
fetch
part du principe que le transfert a réussi — le serveur a été atteint, il a répondu, la réponse est arrivée intacte. Un 404 est une réponse valide à une requête, et non un échec de celle-ci. Le rejeter reviendrait à confondre une défaillance de transport avec la sémantique de l’application. C’est d’ailleurs exactement la position de curl, où un 404 génère également un code de sortie nul.
Axios estime que la plupart des appelants considèrent un code 4xx ou 5xx comme un échec, et qu’il doit donc se comporter comme tel.
En pratique, le modèle d’fetch
est plus correct mais aussi plus sujet aux erreurs, car il exige une discipline à chaque appel et rien ne vous avertit en cas de manquement à cette discipline.
Qu'est-ce que Fetch et combien ça coûte ?
La norme, avec ses avantages et ses lacunes.
Les avantages
Elle est intégrée. Pas de dépendance, pas d'installation, pas de coût lié aux bundles, pas de chaîne d'approvisionnement à auditer. Dans les navigateurs et dans Node moderne, elle est tout simplement là.
C’est une norme. Elle est spécifiée plutôt que maintenue par un projet susceptible de changer d’orientation, d’être abandonné ou d’introduire une modification rompant la compatibilité selon son propre calendrier.
C’est la base. De nombreuses bibliothèques de niveau supérieur s’appuient sur elle ; comprendre l’fetch, c’est donc comprendre leur fonctionnement.
Il gère bien le streaming. Response.body est un flux lisible, ce qui rend naturel le traitement progressif des réponses volumineuses.
Ce qu’il ne fait pas
Ce sont les lacunes que vous comblez vous-même, et leur nombre constitue l’argument de poids en faveur d’Axios.
Pas de JSON automatique. Vous appelez .json(), ce qui représente un autre « await » et un autre point de défaillance si la réponse n’est pas au format JSON — une page d’erreur HTML, par exemple, ce qui est exactement ce que vous obtenez d’un serveur mal configuré.
Pas de rejet de statut. C’est ce qui a été abordé plus haut.
Pas de délai d’expiration par défaut. Une requête fetch peut se bloquer indéfiniment. AbortSignal.timeout() en propose un dans les environnements modernes, mais il faut l’activer manuellement et on oublie facilement de le faire — ce qui est particulièrement gênant précisément dans les situations où un blocage est le plus grave.
Pas d’intercepteurs. Aucun moyen d’associer de manière centralisée un jeton d’authentification, un identifiant de corrélation ou la journalisation. Soit chaque appel le répète, soit vous écrivez un wrapper, et c’est en écrivant un wrapper que les gens finissent par créer accidentellement leur propre version d’Axios, souvent moins performante.
Pas de suivi de la progression du téléchargement. La progression du téléchargement est possible via le flux de réponse ; celle du chargement n’est pas aussi simple.
Pas de sérialisation automatique du corps de la requête. Vous appelez JSON.stringify et définissez vous-même le type de contenu, à chaque fois.
Pas de configuration de proxy dans Node. Une section lui est consacrée ci-dessous.
Le résumé honnête
fetch est une primitive de bas niveau bien conçue. Ses omissions sont délibérées : une norme doit être minimale et neutre.
La question n’est pas de savoir si elle est bonne. Il s’agit plutôt de déterminer si vous souhaitez implémenter vous-même la couche manquante, et si la version que vous implémenterez sera meilleure que celle maintenue par un projet bénéficiant d’une large base d’utilisateurs qui en identifie les cas limites.
Ce qu’Axios vous apporte
D’après sa propre documentation, la liste des fonctionnalités constitue son principal argument de vente.
Client HTTP basé sur les Promises, doté d’une interface cohérente dans tous les environnements, proposant des paquets distincts pour les navigateurs et Node.
Des intercepteurs pour les requêtes et les réponses, ce qui constitue la fonctionnalité la plus précieuse et la plus difficile à reproduire proprement. Ajoutez un en-tête d’authentification une seule fois, gérez le rafraîchissement 401 une seule fois, ajoutez la journalisation une seule fois — et chaque requête de l’application en hérite.
Gestion automatique du format JSON dans les deux sens. Les corps de requête sont sérialisés et le type de contenu est défini ; les réponses sont analysées en objets response.data.
Gestion des erreurs avec rejet des statuts autres que 2xx.
Configuration du délai d’expiration, décrite dans la documentation comme empêchant les blocages indéfinis des requêtes. Une seule valeur de configuration plutôt qu’un contrôleur d’abandon par appel.
Annulation des requêtes en cours.
Suivi de la progression pour les téléchargements ainsi que pour les envois, ce que fetch ne propose pas directement.
Protection XSRF intégrée.
Envoi de fichiers et données de formulaire multipart gérés pour vous.
Limitation du débit et régulation des requêtes.
Instances avec paramètres par défaut : un client configuré avec une URL de base, des en-têtes et un délai d’expiration peut ainsi être créé une seule fois et importé partout.
Les coûts
Une dépendance. Quelque chose à installer, à maintenir à jour et à auditer. Dans un environnement soucieux de la sécurité, cela représente un coût réel plutôt que théorique.
Taille du bundle. Significative pour un petit front-end, négligeable pour une grande application ou tout élément côté serveur.
Une abstraction supplémentaire à maîtriser, qui se comporte parfois de manière inattendue par rapport à la plateforme sous-jacente.
Une vision objective
Axios correspond à peu près à ce que la plupart des gens finissent par développer par-dessus fetch lorsqu’ils ont besoin de ces fonctionnalités — sauf qu’il est déjà écrit, déjà débogué et qu’il gère déjà les cas auxquels vous n’avez pas pensé.
Si vous n’avez besoin d’aucune de ces fonctionnalités, c’est une dépendance inutile.
Comparaison côte à côte
| fetch | Axios |
|---|
| Installation | Intégrée | npm install |
| Rejette les erreurs 404/500 | Non | Oui |
| Analyse JSON | Manuelle .json() | Automatique |
| Sérialisation du corps de la requête | Manuelle | Automatique |
| Délai d'expiration | AbortSignal.timeout() | Option de configuration |
| Intercepteurs | Non | Oui |
| Progression du téléchargement | Pas simple | Oui |
| Progression du téléchargement | Via le flux de réponse | Oui |
| Annulation | AbortController | Intégrée |
| Protection XSRF | Manuelle | Intégrée |
| Instances avec valeurs par défaut | Non | Oui |
| Configuration du proxy dans Node | Non | Oui |
| Streaming | Excellent | Plus limité |
| Coût du bundle | Zéro | Faible mais non nul |
La même requête, de deux façons différentes
// fetch, written correctly
const res = await fetch('https://api.example.com/users', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'Authorization': `Bearer ${token}`
},
body: JSON.stringify({ name: 'Alice' }),
signal: AbortSignal.timeout(5000)
});
if (!res.ok) throw new Error(`HTTP ${res.status}`);
const data = await res.json();
// Axios
const { data } = await axios.post(
'https://api.example.com/users',
{ name: 'Alice' },
{ headers: { Authorization: `Bearer ${token}` }, timeout: 5000 }
);
Les deux sont correctes. La version fetch compte onze lignes contre cinq pour Axios, et la différence réside entièrement dans des éléments que vous devez garder à l’esprit à chaque appel plutôt que de les configurer une seule fois.
Les deux lignes qui font la différence
Rejets en cas de 404/500 et configuration du proxy dans Node sont les seules lignes où un outil ne peut pas faire directement ce que fait l’autre. Le reste est du code standard, et le code standard représente un coût plutôt qu’une impossibilité.
Le « Boilerplate Tax »
La véritable comparaison ne porte pas sur un appel à fetch
par rapport à un appel à axios
. Elle porte sur une base de code utilisant l’un ou l’autre.
Ce que tout le monde finit par écrire
Après avoir répété trois ou quatre fois la vérification de l’état, le délai d’expiration et l’analyse du JSON, vous écrivez ceci :
async function request(url, options = {}) {
const res = await fetch(url, {
...options,
headers: {
'Content-Type': 'application/json',
...(token && { Authorization: `Bearer ${token}` }),
...options.headers
},
signal: options.signal ?? AbortSignal.timeout(options.timeout ?? 10000)
});
if (!res.ok) {
const body = await res.text();
throw new HttpError(res.status, body);
}
return res.status === 204 ? null : res.json();
}
C’est un wrapper raisonnable et plutôt efficace. C’est aussi, sans aucun doute, un petit Axios.
Ce que le wrapper ne gérera pas tant que personne ne s’en rendra compte
Nouvelle tentative avec délai d’attente. Actualisation du jeton en cas de code 401 sans « tempête de requêtes » lorsque plusieurs appels échouent simultanément. Requêtes renvoyant du HTML au lieu de JSON. Réponses 204 sans corps. Annulation propagée à travers des appels imbriqués. Progression du téléchargement. Types de contenu autres que JSON. Identifiants de corrélation pour le traçage.
Chacun de ces éléments est un petit ajout. Ensemble, ils forment une bibliothèque, et la version que vous écrivez sera moins testée que celle que des milliers de personnes utilisent déjà.
Quand il est judicieux de l’écrire soi-même
Lorsque vous n’en avez que très peu besoin. Une poignée de requêtes GET vers une seule API. Le wrapper ci-dessus compte trente lignes et vous en êtes entièrement maître.
Lorsque la taille du bundle a vraiment de l’importance. Une page où les performances sont cruciales et où chaque kilo-octet compte.
Lorsque les dépendances coûtent cher. Des environnements où chaque paquet doit faire l’objet d’une validation.
Lorsque vous souhaitez comprendre la plateforme. Une raison légitime, et cette compréhension est transférable.
Quand ce n’est pas le cas
Lorsque vous en êtes à votre troisième itération de wrapper, lorsque différentes parties du code utilisent des wrappers différents, ou lorsque vous ajoutez une logique de réessai. À ce stade, vous gérez une bibliothèque comme un projet parallèle, et la dépendance que vous avez évitée revient moins cher que celle que vous avez créée.
Taille du bundle et la question des nœuds
Les deux facteurs contextuels qui font varier la réponse.
Dans le navigateur
Axios alourdit votre bundle. L’importance de ce facteur dépend entièrement de ce que vous développez.
Une page d’accueil ou un widget où le temps de chargement est le produit : utilisez fetch. Chaque kilo-octet compte, et les schémas de requêtes sont généralement suffisamment simples pour que le code standard soit insignifiant.
Une application volumineuse intégrant déjà un framework et une bibliothèque de composants : le coût marginal est négligeable, et la prise en charge des intercepteurs vaut bien plus que les octets supplémentaires.
En réalité, la taille du bundle est l’argument auquel les gens ont recours lorsqu’ils cherchent une justification technique à une préférence esthétique. C’est un facteur réel, mais il est bien moins souvent déterminant qu’on ne le prétend.
Sous Node
Le calcul est totalement différent. La taille du bundle n’a aucune importance sur un serveur, ce qui fait disparaître le principal argument contre Axios.
L’fetche native est disponible dans les versions modernes de Node et fonctionne bien. Mais le code côté serveur a souvent besoin précisément de ce qu’fetch omet : des délais d’expiration pour tout, des tentatives de réessai avec backoff, une gestion centralisée de l’authentification, une journalisation structurée des appels sortants et — comme l’aborde la section suivante — la configuration de proxy.
La balance penche donc davantage en faveur d’Axios sur le serveur que dans le navigateur, ce qui va à l’encontre de la façon dont l’argumentation est généralement menée.
Le compromis dont personne ne parle
Vous pouvez utiliser les deux. fetch pour les appels simples, Axios lorsque vous avez besoin de la machinerie. Rien ne l’interdit et l’argument de la cohérence est moins solide qu’il n’y paraît.
Ce qui pose véritablement problème, ce sont trois wrappers maison différents dans une même base de code, chacun gérant les erreurs de manière légèrement différente. C’est pire que d’utiliser l’une ou l’autre bibliothèque de manière cohérente, et c’est pourtant la situation dans laquelle se retrouve un nombre surprenant de projets.
Les proxys dans les deux cas
Notre domaine de prédilection, et la source d’un après-midi véritablement déroutant pour de nombreux développeurs.
En bref
L’fetche native de Node ne lit pas les variables d’environnement standard relatives aux proxys. Définir HTTP_PROXY et HTTPS_PROXY n’a aucun effet, contrairement à curl, contrairement à la plupart des bibliothèques HTTP, et contrairement à ce à quoi presque tout le monde s’attend.
L’fetch, la variable globale de Node, repose sur undici, et le routage via un proxy nécessite de spécifier explicitement un dispatcher :
import { ProxyAgent, setGlobalDispatcher } from 'undici';
setGlobalDispatcher(new ProxyAgent('http://user:pass@proxy.example.com:8080'));
// now fetch goes through the proxy
const res = await fetch('https://example.com');
Ou pour chaque requête, en passant l’option dispatcher.
Axios sous Node
Axios dispose d’une option de configuration « proxy » :
const res = await axios.get('https://example.com', {
proxy: {
protocol: 'http',
host: 'proxy.example.com',
port: 8080,
auth: { username: 'user', password: 'pass' }
}
});
Pour les proxys SOCKS, ou pour un contrôle plus fin, l’approche habituelle consiste à utiliser une bibliothèque d’agent transmise via les paramètres « httpAgent » et « httpsAgent ».
Dans le navigateur, aucun des deux ne le peut
Cela vaut la peine d’être précisé, car cela permet de gagner du temps. JavaScript dans un navigateur ne peut pas configurer de proxy. Le navigateur utilise ce qui a été configuré par le système ou par une extension, et aucune bibliothèque ne peut modifier cela. L’option proxy d’Axios est une fonctionnalité de Node.
Si vous avez besoin de requêtes relayées par un proxy à partir d’un code exécuté dans un navigateur, la requête doit passer par un serveur que vous contrôlez.
L’indice de débogage
Si un proxy « ne fonctionne pas » sous Node, vérifiez quel client effectue la requête avant toute autre chose. Un code qui fonctionne avec Axios et échoue avec fetch — ou inversement — est presque toujours dans ce cas, et cela passe inaperçu car aucun des deux ne génère d’erreur. La requête est simplement envoyée directement.
Vérifiez cela en envoyant une requête vers un point de terminaison de rapport d’adresse via votre client configuré et en vous assurant que l’adresse renvoyée est bien celle du proxy.
Et la partie qui va à l’encontre de nos propres intérêts
La plupart des appels HTTP côté serveur ne nécessitent absolument aucun proxy. Appeler une API pour laquelle vous disposez d’identifiants, depuis un serveur autorisé à y accéder, ne nécessite rien de plus — un proxy ajoute de la latence, un point de défaillance et des coûts. Les proxys trouvent leur utilité pour la vérification géographique et pour la collecte en volume lorsque des limites de débit par adresse s’appliquent. En dehors de cela, le client « simple » est le meilleur choix.
Quel choix faire ?
Une liste de critères plutôt qu'un verdict.
Utilisez « fetch » lorsque
La taille du bundle est véritablement cruciale. Pages de destination, widgets, scripts intégrés.
Vos requêtes sont simples. Quelques requêtes GET, une gestion minimale des erreurs, aucune authentification partagée.
Vous ne pouvez pas ajouter de dépendances, ou chaque bibliothèque nécessite une validation.
Vous travaillez avec des flux. Le modèle de streaming d’fetch est meilleur, ce qui constitue un véritable avantage technique plutôt qu’une simple préférence.
Vous souhaitez vous familiariser avec la plateforme. Les connaissances sont transférables ; celles spécifiques à Axios ne le sont pas.
Utilisez Axios lorsque
Vous avez besoin d’intercepteurs. Authentification centralisée, rafraîchissement des jetons, journalisation, identifiants de corrélation. C’est la raison la plus importante et il n’existe aucun équivalent clair dans l’fetch.
Vous êtes côté serveur. La taille du bundle n’est pas un problème et les fonctionnalités manquantes correspondent exactement aux besoins du code serveur.
Vous avez besoin de suivre la progression d’un téléchargement, ce qu’fetch ne facilite pas.
Vous effectuez de nombreuses requêtes variées au sein d’une base de code étendue et souhaitez un comportement cohérent sans avoir à maintenir un wrapper.
Vous avez besoin d’une configuration de proxy et préférez utiliser une option documentée plutôt que de créer un dispatcher.
Quel que soit votre choix
Définissez toujours un délai d’expiration. AbortSignal.timeout() ou l’option timeout d’Axios. Une requête sans délai d’expiration peut se bloquer indéfiniment, ce qui constitue le défaut de fiabilité le plus courant dans le code HTTP JavaScript.
Vérifiez toujours le statut avec fetch. À chaque appel, sans exception. « res.ok » : ces deux mots, et leur absence, constituent le bug évoqué au début de cet article.
Centralisez-le. Un wrapper ou une instance Axios configurée. Trois approches incohérentes dans une même base de code sont pires que n’importe laquelle de ces bibliothèques, et c’est un résultat que personne ne choisit délibérément.
Questions fréquentes
Quelle est la principale différence entre Axios et fetch ?
La gestion des erreurs. Selon MDN, une promesse « fetch » « ne rejette pas la requête si le serveur répond avec des codes d'état HTTP indiquant des erreurs » — vous devez vérifier vous-même l'response.ok. Axios rejette les statuts autres que 2xx. Tout le reste relève de la commodité : Axios ajoute des intercepteurs, la conversion automatique en JSON, les délais d'expiration, la progression et la configuration de proxy.
Axios est-il encore nécessaire maintenant que fetch est intégré ?
Cela dépend de vos besoins. Pour les requêtes simples, non. Pour les intercepteurs, la progression des téléchargements, les paramètres par défaut par instance ou la configuration de proxy Node, Axios offre toujours des fonctionnalités que fetch ne propose pas, et les implémenter soi-même impliquerait de maintenir une petite bibliothèque.
Pourquoi fetch ne lève-t-il pas d’exception en cas de 404 ?
Parce que le transfert a réussi : le serveur a été atteint et a répondu. fetch traite un 404 comme une réponse valide plutôt que comme une requête ayant échoué, et ne rejette que les erreurs réseau ou les URL mal formées. Vérifiez response.ok à chaque appel.
Qu’est-ce qui est le plus rapide, Axios ou fetch ?
Pour une requête unique, la différence est négligeable ; les deux dépendent du réseau. Axios ajoute un léger surcoût de traitement et, dans le navigateur, un petit téléchargement pour la bibliothèque elle-même.
Comment définir un délai d’expiration avec fetch ?
AbortSignal.timeout(5000) En le passant comme option « signal » dans les environnements modernes, ou via un « AbortController » avec votre propre temporisateur. Il n’y a pas de délai d’expiration par défaut ; une requête sans délai d’expiration peut donc rester bloquée indéfiniment.
« fetch » fonctionne-t-il avec des proxys sous Node ?
Pas via les variables d’environnement habituelles. La variable globale « fetch » de Node repose sur undici et ne lit pas les fichiers « HTTP_PROXY » ni « HTTPS_PROXY ». Vous devez fournir un dispatcher ProxyAgent, soit globalement avec setGlobalDispatcher, soit par requête. Axios dispose à la place d’une option de configuration proxy.
Puis-je utiliser un proxy avec fetch dans le navigateur ?
Non. Le JavaScript du navigateur ne peut pas configurer de proxy — le navigateur utilise les paramètres du système ou ceux des extensions. L’option de proxy de toute bibliothèque est une fonctionnalité réservée à Node. Les requêtes relayées par un proxy depuis le navigateur doivent passer par un serveur que vous contrôlez.
Dois-je utiliser à la fois Axios et fetch dans un même projet ?
Ce n’est pas un problème en soi. Ce qui pose vraiment problème, ce sont plusieurs wrappers maison incohérents présentant des comportements différents en cas d’erreur. La cohérence dans la gestion des échecs importe davantage que la bibliothèque à l’origine de la requête.
Conclusion
Une seule différence est de fond, les autres relèvent de la préférence.
fetch ne rejette pas les erreurs HTTP. MDN l’indique explicitement : un code 404 ou 504 est résolu, et vous devez vérifier vous-même response.ok ou response.status. Si vous négligez cette vérification lors d’un appel, l’échec se manifestera ailleurs, sous la forme d’une erreur déroutante concernant des données qui n’ont jamais été valides. Axios rejette par défaut les codes d’état autres que 2xx. Les deux positions sont défendables ; seule l’une d’entre elles exige de la rigueur à chaque appel, et la rigueur n’est pas une qualité que les bases de code conservent lorsqu’elles sont soumises à des délais.
Tout le reste dépend de ce que vous développez. Dans le navigateur, fetch est intégré et gratuit, et pour les modèles de requêtes simples, le code standard est insignifiant. Côté serveur, la taille du bundle n’a plus d’importance et les fonctionnalités que fetch omet — délais d’expiration, intercepteurs, réessais, configuration de proxy — sont précisément ce dont le code serveur a besoin, ce qui fait pencher la balance dans l’autre sens.
Le test à effectuer : si vous avez écrit un wrapper autour de fetch et qu’il compte désormais plus d’une trentaine de lignes, vous gérez une petite bibliothèque HTTP. C’est un choix légitime s’il est délibéré, mais un mauvais choix s’il est le fruit du hasard.
Concernant les proxys, et c’est là que les gens perdent souvent un après-midi : l’fetch native dans Node ignore les variables d’environnement standard relatives aux proxys. Définir HTTPS_PROXY ne change rien, la requête est envoyée directement et aucune erreur n’est signalée. Fournissez un dispatcher undici ProxyAgent, ou utilisez l’option proxy`` d’Axios — et vérifiez auprès d’un point de terminaison signalant l’adresse plutôt que de partir d’une hypothèse.
Nous commercialisons des proxys, mais la plupart des requêtes côté serveur n’en ont pas besoin. Lorsque vous en avez besoin, déterminer quel client vous utilisez constitue la première étape du débogage, et non la dernière.
