curl
RéseauPaquet : curl
Envoie une requête HTTP (ou autre) et montre la réponse. curl -I ne lit que les en-têtes, -v montre l'échange complet, TLS compris — c'est ainsi qu'on distingue « le serveur répond mal » de « le serveur ne répond pas ».
Ce que font ses options dans les leçons
Tiré du même glossaire que les leçons affichent sous leurs commandes ; les deux ne peuvent pas se contredire.
curl -I- Requête HEAD : ne récupère que les en-têtes.
curl -v- Mode bavard : montre chaque étape de la connexion — dont celle qui échoue — avant le moindre échange HTTP.
curl -L- Suit les redirections au lieu de s'arrêter sur la réponse 3xx.
curl -s- Silencieux : ni barre de progression ni message d'erreur.
curl -S- Avec
-s, réaffiche quand même les erreurs.-sSdonne « silencieux mais pas muet ». curl -f- Échoue avec un code de retour non nul sur une réponse HTTP ≥ 400, au lieu d'enregistrer la page d'erreur comme si c'était le contenu attendu.
curl -w- Écrit un modèle après la réponse, où
%{http_code}est remplacé par le code HTTP. Avec-o /dev/null, la page est jetée et il ne reste que le chiffre — ce qu'une vérification veut lire. curl -H- Ajoute un en-tête à la requête.
-H 'Host: exemple.fr'fait choisir au serveur web l'hôte virtuel de ce nom alors que vous interrogez une adresse IP nue : c'est ainsi qu'on teste un site avant que le DNS ne le désigne. curl -o- Écrit dans un fichier au lieu de la sortie standard.
curl -m- Durée maximale de l'ensemble du transfert, en secondes. Sans elle, un script de vérification peut attendre indéfiniment.
curl --data-binary- Envoie le corps de la requête tel quel, sans réencodage ni suppression des retours à la ligne, contrairement à
-d. La forme@fichierlit le corps dans un fichier : c'est ce qu'il faut pour tester une limite de taille avec des octets réels. curl --resolve- Associe un nom d'hôte à l'adresse que vous choisissez, pour cette requête seulement (
--resolve exemple.fr:443:198.51.100.25). Sert à tester le vhost et le certificat d'une nouvelle machine alors que le DNS pointe encore l'ancienne.
Les leçons qui l'enseignent
- Refusé ou silencieux : ce que chaque échec prouveRéseau : comment votre serveur est joignable
- Injoignable : trouver la couche en panne avant de toucher à quoi que ce soitRéseau : comment votre serveur est joignable
- Ça marche sur le serveur, refusé depuis l'extérieurRéseau : comment votre serveur est joignable
- Servir un build React/ViteHéberger une application web avec Nginx
- Quel bloc serveur répond, et pourquoi c'est parfois le mauvais siteHéberger une application web avec Nginx
- Les limites qui refusent : 413 et 504Héberger une application web avec Nginx
- Les en-têtes que vous croyez avoir posésHéberger une application web avec Nginx
- Créer un site, puis y placer une application Node.jsISPConfig : héberger plusieurs sites sur un serveur
- Reconstruire la machine entière, dans le bon ordreSauvegardes et restaurations
- Une vérification automatique qui sert à quelque choseSurveiller un serveur
- Publier les enregistrements, et vérifier avant de continuerDNS : faire pointer un domaine vers votre serveur
- Pourquoi corriger la faute de frappe ne suffit pas encoreDNS : faire pointer un domaine vers votre serveur
- Déplacer un domaine vivant : la bascule est la partie la plus courteDNS : faire pointer un domaine vers votre serveur
- Du symptôme à un composant : ce que l'hypothèse interditDiagnostiquer une panne : ce que chaque sortie prouve
- Capturer avant de réparer : ce qu'un redémarrage emporteDiagnostiquer une panne : ce que chaque sortie prouve
- Vérifier avant de se déclarer terminé, et ce qu'un retour n'annule pasDéployer : releases, bascule et retour arrière
- La mise en production qui casse : replier d'abord, diagnostiquer ensuiteProjet final : du dépôt à la production
