HTTP et HTTPS : le protocole du Web

HTTP (HyperText Transfer Protocol) est le protocole qui permet à votre navigateur de communiquer avec les serveurs web. Chaque fois que vous visitez une page, votre navigateur envoie une requête et le serveur renvoie une réponse avec un code de statut (200 OK, 404 Not Found, etc.). HTTPS ajoute une couche de chiffrement TLS pour sécuriser les échanges. Ce guide vous apprend à comprendre et diagnostiquer les communications HTTP avec curl.

TL;DR, L'essentiel en 30 secondes

Si vous arrivez ici en pleine investigation, ces quatre points suffisent à poser le diagnostic. Le plus rentable est le troisième : la famille du code vous dit immédiatement de quel côté chercher, chez l'appelant pour un 4xx, sur le serveur pour un 5xx.

• HTTP = requête (GET/POST) → réponse (code + contenu)
• HTTPS = HTTP + chiffrement TLS (port 443 au lieu de 80)
• 200 = OK, 4xx = erreur client (404 = introuvable), 5xx = erreur serveur
• curl -I url : voir les headers et le code de statut

Je sais que c'est bon si...

Ces trois points servent d'auto-évaluation avant de lire la suite. Si vous les cochez tous, ce guide vous servira surtout de référence pour les sections TLS et diagnostic. Le deuxième point est le plus discriminant : la confusion entre 401 et 403 est la cause la plus fréquente de temps perdu sur un incident d'API, parce qu'elle oriente l'enquête vers le mauvais système.

• curl -I https://google.com retourne "200 OK" ou "301/302"
• Je sais distinguer 401 (pas authentifié) de 403 (pas autorisé)
• curl -w "%{http_code}\n" -s -o /dev/null url me donne le code HTTP

Commandes minimales à retenir

Ces trois commandes couvrent trois besoins distincts, et c'est cette progression qu'il faut mémoriser. La première répond à « que renvoie le serveur », la deuxième à « le service est-il vivant » sous une forme exploitable par un script, la troisième à « où exactement ça casse ». Passez à -v seulement quand les deux premières ne suffisent pas : sa sortie est verbeuse et noie l'information si vous n'avez pas d'hypothèse.

# 1. Voir les headers de réponse
curl -I https://github.com

# 2. Obtenir juste le code HTTP
curl -s -o /dev/null -w "%{http_code}\n" https://api.example.com/health

# 3. Débugger une connexion (DNS, TCP, TLS, HTTP)
curl -v https://api.example.com

HTTP/1.1, HTTP/2, HTTP/3 : même sémantique

Ce module couvre la sémantique HTTP (RFC 9110) : méthodes, headers, codes de statut. Ces concepts restent identiques quelle que soit la version du protocole. Seul le format sur le fil change (texte en HTTP/1.1, binaire multiplexé en HTTP/2, QUIC en HTTP/3).

Ce que vous allez apprendre

• Lire un échange HTTP : décomposer une requête (méthode, URL, headers, body) et une réponse.
• Interpréter les codes de statut (2xx, 3xx, 4xx, 5xx) pour diagnostiquer une panne en quelques secondes.
• Distinguer les méthodes GET, POST, PUT, PATCH, DELETE et comprendre l'idempotence.
• Comprendre HTTPS et le handshake TLS 1.3 : chiffrement, certificat, Forward Secrecy.
• Diagnostiquer avec curl et openssl : headers, code HTTP, version TLS négociée, timing.

Prérequis

• Connaissances de base en réseau (IP, ports)
• Un terminal Linux, macOS ou WSL
• curl installé (présent par défaut sur la plupart des systèmes)

Vérifier curl

Vérifiez que curl est installé avec curl --version. Sinon, installez-le avec sudo apt install curl (Debian/Ubuntu) ou brew install curl (macOS).

Quick check en 60 secondes (si vous êtes en incident)

Si vous avez un problème HTTP/HTTPS maintenant, voici la séquence de diagnostic :

# 1. Résolution DNS
dig +short api.example.com

# 2. Connectivité TCP (port 443 = HTTPS, 80 = HTTP)
nc -zv api.example.com 443

# 3. Handshake TLS + headers (k = ignore cert pour test)
curl -vkI https://api.example.com

# 4. Code de statut HTTP uniquement
curl -s -o /dev/null -w "%{http_code}\n" https://api.example.com/health

# 5. Si 5xx : vérifier les logs
# - Logs du reverse proxy (nginx, haproxy)
# - Logs du backend applicatif

Code 000 = pas de réponse HTTP

Si curl retourne 000, la connexion a échoué avant d'obtenir une réponse HTTP (DNS, TCP, TLS). Utilisez curl -v pour identifier l'étape bloquante.

Le cycle requête/réponse HTTP

HTTP fonctionne sur un modèle simple : le client (votre navigateur ou curl) envoie une requête au serveur, qui renvoie une réponse.

Structure d'une requête HTTP

Quatre éléments composent une requête, mais seuls deux sont obligatoires en HTTP/1.1 : la méthode avec son URL, et le header Host. Ce dernier existe parce qu'un même serveur héberge en général plusieurs domaines sur la même adresse IP ; sans lui, il ne saurait pas quel site servir. Le body est absent des requêtes GET et HEAD, ce qui explique pourquoi on ne peut pas envoyer de données de recherche complexes autrement que dans l'URL.

Élément	Description	Exemple
Méthode	L'action demandée	GET, POST, PUT, DELETE
URL	La ressource ciblée	/api/users/123
Headers	Métadonnées de la requête	Host: example.com, User-Agent: curl/7.68
Body	Données envoyées (POST/PUT)	{"name": "Jean", "email": "jean@example.com"}

Glissez pour voir

Structure d'une réponse HTTP

La réponse suit la même découpe, avec une différence de méthode de lecture : c'est le code de statut qu'on regarde en premier, parce qu'il détermine si le body a un sens. Un 404 accompagné d'un body HTML n'est pas votre page, c'est la page d'erreur du serveur. Le header Content-Type sert ensuite à savoir comment interpréter ce body, et c'est lui qu'on vérifie quand une API renvoie du HTML là où on attendait du JSON, signe classique d'un reverse proxy qui a intercepté la requête.

Élément	Description	Exemple
Code de statut	Résultat de la requête	200 OK, 404 Not Found
Headers	Métadonnées de la réponse	Content-Type: application/json
Body	Contenu retourné	HTML, JSON, image...

Glissez pour voir

Les méthodes HTTP

HTTP définit plusieurs méthodes (aussi appelées "verbes") qui indiquent l'action souhaitée sur une ressource.

Méthode	Usage	Idempotent ?
GET	Récupérer une ressource	Oui
POST	Créer une ressource	Non
PUT	Remplacer une ressource	Oui
PATCH	Modifier partiellement	Non
DELETE	Supprimer une ressource	Oui
HEAD	Récupérer les headers seulement	Oui
OPTIONS	Connaître les méthodes autorisées	Oui

Glissez pour voir

Idempotent ?

Une opération idempotente produit le même résultat qu'on l'exécute 1 ou 100 fois. GET /users/1 retourne toujours le même utilisateur. DELETE /users/1 supprime l'utilisateur, mais l'appeler deux fois ne change rien de plus.

Les codes de statut HTTP

Les codes de statut sont regroupés en 5 familles selon leur premier chiffre. Connaître les plus courants vous fera gagner un temps précieux en diagnostic.

Famille 2xx : Succès

Le serveur a traité la requête avec succès. La nuance entre les trois codes ci-dessous porte sur le contenu retourné, pas sur la réussite : 201 doit s'accompagner d'un header Location pointant vers la ressource créée, et 204 interdit tout body. Une API qui renvoie 200 avec un body vide après une suppression n'est pas fausse, mais elle est moins précise que 204.

Code	Nom	Signification
200	OK	Requête réussie, contenu retourné
201	Created	Ressource créée (après POST)
204	No Content	Succès sans contenu (après DELETE)

Glissez pour voir

Famille 3xx : Redirections

Le client doit aller chercher la ressource ailleurs, à l'adresse indiquée par le header Location. La colonne « Méthode conservée » est celle qui compte pour une API : elle vous dit si un POST redirigé restera un POST. Le code 304 est à part, il ne redirige rien et signifie « votre copie en cache est encore bonne », d'où la mention N/A.

Code	Nom	Signification	Méthode conservée ?
301	Moved Permanently	Redirection permanente	Non (peut devenir GET)
302	Found	Redirection temporaire	Non (peut devenir GET)
307	Temporary Redirect	Redirection temporaire	Oui
308	Permanent Redirect	Redirection permanente	Oui
304	Not Modified	Ressource en cache encore valide	N/A

Glissez pour voir

301/302 vs 307/308

Historiquement, 301 et 302 pouvaient transformer un POST en GET lors de la redirection (comportement des navigateurs). 307 et 308 garantissent que la méthode HTTP est conservée. Pour une API REST, préférez 307/308. Référence : MDN HTTP Status Codes.

Famille 4xx : Erreurs client

La requête est mal formée ou non autorisée. Ces codes désignent une faute côté client, ce qui a une conséquence pratique : réessayer à l'identique ne servira à rien, sauf pour le 429 qui demande justement d'attendre. Quand vous voyez un 4xx en production, cherchez d'abord ce que l'appelant envoie, pas ce que le serveur fait.

Code	Nom	Signification
400	Bad Request	Requête mal formée (JSON invalide, paramètre manquant)
401	Unauthorized	Authentification requise
403	Forbidden	Authentifié mais pas autorisé
404	Not Found	Ressource inexistante
405	Method Not Allowed	Méthode non supportée sur cette URL
429	Too Many Requests	Rate limiting déclenché

Glissez pour voir

401 vs 403

401 Unauthorized : le serveur ne sait pas qui vous êtes (pas de token, token expiré).

403 Forbidden : le serveur sait qui vous êtes mais vous n'avez pas les droits.

Famille 5xx : Erreurs serveur

Le serveur a rencontré un problème, et la requête était probablement valide. La distinction entre ces quatre codes localise la panne : 500 désigne le code applicatif, tandis que 502, 503 et 504 viennent presque toujours d'un reverse proxy qui n'obtient pas de réponse utilisable de son backend. Cette information vous dit dans quels journaux chercher.

Code	Nom	Signification
500	Internal Server Error	Bug côté serveur
502	Bad Gateway	Le reverse proxy ne joint pas le backend
503	Service Unavailable	Serveur surchargé ou en maintenance
504	Gateway Timeout	Le backend ne répond pas à temps

Glissez pour voir

HTTP vs HTTPS : le chiffrement TLS

HTTP transmet les données en clair. Quiconque intercepte le trafic peut lire vos identifiants, vos données personnelles. HTTPS (HTTP Secure) chiffre la communication avec TLS (Transport Layer Security).

Différences clés

Une seule ligne de ce tableau explique toutes les autres : le certificat. C'est lui qui apporte l'identité du serveur, et sans identité vérifiée, le chiffrement ne protégerait de rien puisque vous pourriez négocier une session chiffrée avec un attaquant. Notez aussi la ligne Intégrité : HTTPS ne se contente pas de rendre le trafic illisible, il rend toute modification en transit détectable, ce qui bloque l'injection de contenu par un intermédiaire.

Aspect	HTTP	HTTPS
Port	80	443
Chiffrement	Aucun	TLS (AES-GCM, ChaCha20-Poly1305)
Certificat	Non requis	Obligatoire
Confidentialité	Aucune	Données illisibles sans clé
Intégrité	Aucune	Modification détectable

Glissez pour voir

Ports officiels

Les ports 80 (HTTP) et 443 (HTTPS) sont définis dans le registre IANA. En pratique, vous pouvez utiliser n'importe quel port, mais ces valeurs sont les standards.

Le handshake TLS simplifié (TLS 1.3)

En TLS moderne (RFC 8446), l'établissement de connexion sécurisée utilise un échange de clés Diffie-Hellman éphémère (ECDHE), pas un chiffrement RSA de la clé de session (méthode obsolète).

1. Client Hello

   Le client envoie la liste des algorithmes supportés, un nombre aléatoire, et sa contribution ECDHE (clé publique éphémère).

2. Server Hello

   Le serveur choisit les algorithmes, envoie son certificat, sa contribution ECDHE, et une signature prouvant son identité.

3. Vérification du certificat

   Le client vérifie que le certificat est signé par une autorité de confiance (CA) et que le nom de domaine correspond (CN ou SAN).

4. Dérivation des clés de session

   Les deux parties combinent leurs contributions ECDHE pour calculer un secret partagé, d'où sont dérivées les clés de chiffrement. Personne d'autre ne peut calculer ce secret.

5. Communication chiffrée

   Tout le trafic HTTP est chiffré avec les clés de session (AES-GCM ou ChaCha20-Poly1305).

Cette mécanique apporte une propriété qui porte un nom : la Forward Secrecy. Comme la clé de session naît d'un calcul jetable propre à chaque connexion et n'est jamais transmise, la compromission ultérieure de la clé privée du serveur ne permet pas de déchiffrer les sessions passées, même enregistrées à l'avance par un attaquant. On parle de Perfect Forward Secrecy (PFS), garanti par construction en TLS 1.3.

Reste à savoir ce que ce chiffrement recouvre exactement. Sont chiffrés tous les headers HTTP et le body, ce qui inclut le chemin de l'URL, les cookies et les données transmises. Restent visibles l'adresse IP de destination et, par défaut, le SNI (Server Name Indication), c'est-à-dire le nom de domaine demandé. Un observateur du réseau sait donc quel site vous consultez, mais pas quelle page. Le mécanisme ECH (Encrypted Client Hello) chiffre ce dernier élément, sans être encore généralisé.

Certificats gratuits avec Let's Encrypt

Let's Encrypt fournit des certificats TLS gratuits et automatisables.

En 2026, la tendance est aux durées de vie courtes : Let's Encrypt propose désormais des profils à 45 jours, voire des certificats de 6 jours. Cette évolution rend l'automatisation du renouvellement via le protocole ACME (certbot, acme.sh, ou un serveur web comme Caddy) indispensable, et non plus optionnelle.

Headers HTTP essentiels (DevOps)

En diagnostic, vous manipulerez souvent les headers regroupés ci-dessous. Ils sont classés selon leur sens de circulation, parce que c'est ce qui détermine qui est responsable de leur valeur : un header de requête vient du client et ne doit jamais être cru sur parole, un header de réponse vient du serveur et impose un comportement au client.

Headers de requête

Sur les cinq headers ci-dessous, deux méritent une attention particulière en exploitation. Host est le seul obligatoire, et une valeur incorrecte fait répondre le mauvais site sans aucune erreur visible. Authorization transporte le jeton en clair dans le header : il n'est protégé que par TLS, ce qui rend toute journalisation brute des requêtes dangereuse, puisque le jeton finirait dans vos fichiers de logs.

Header	Rôle	Exemple
Host	Domaine ciblé (obligatoire en HTTP/1.1)	Host: api.example.com
Authorization	Authentification	Authorization: Bearer eyJhbG...
Content-Type	Format des données envoyées	Content-Type: application/json
Accept	Format attendu en réponse	Accept: application/json
User-Agent	Identification du client	User-Agent: curl/7.68.0

Glissez pour voir

Headers de réponse

Ces quatre headers portent des décisions que le serveur impose au client. Cache-Control est celui qui produit le plus d'incidents en apparence inexplicables : une valeur trop généreuse fait servir une version périmée pendant des heures après un déploiement. Quand une correction ne semble pas prise en compte, c'est le premier header à examiner, avant de suspecter le déploiement lui-même.

Header	Rôle	Exemple
Content-Type	Format du contenu retourné	Content-Type: text/html; charset=UTF-8
Location	URL de redirection (3xx)	Location: https://www.example.com/
Cache-Control	Politique de cache	Cache-Control: max-age=3600
Set-Cookie	Créer un cookie	Set-Cookie: session=abc123; HttpOnly

Glissez pour voir

Headers proxy (reverse proxy)

Dès qu'un reverse proxy s'intercale, l'application ne voit plus que l'IP du proxy. Ces headers rétablissent l'information d'origine, et c'est une source classique de faille : ils sont ajoutés par le proxy, mais un client peut aussi les envoyer lui-même. Une application qui fait confiance à X-Forwarded-For sans vérifier que la requête vient bien du proxy laisse n'importe qui usurper son adresse, et donc contourner un filtrage par IP ou une limitation de débit.

Header	Rôle	Exemple
X-Forwarded-For	IP réelle du client	X-Forwarded-For: 203.0.113.42
X-Forwarded-Proto	Protocole original	X-Forwarded-Proto: https
X-Real-IP	IP du client (alternative)	X-Real-IP: 203.0.113.42

Glissez pour voir

# Exemple : envoyer un header personnalisé
curl -H "Authorization: Bearer mon_token" \
     -H "Accept: application/json" \
     https://api.example.com/users

curl : l'outil de diagnostic HTTP

curl (Client URL) est l'outil incontournable pour tester des APIs et diagnostiquer des problèmes HTTP depuis le terminal.

Requête GET simple

curl https://httpbin.org/get

Cette commande envoie une requête GET et affiche la réponse JSON.

httpbin.org : outil de test HTTP

httpbin.org est un service gratuit pour tester les requêtes HTTP. Si vous êtes dans un environnement réseau restreint (proxy, firewall), remplacez par votre endpoint interne (ex: /health ou /api/ping).

Voir les headers de réponse

curl -I https://example.com

L'option -I (ou --head) envoie une requête HEAD et n'affiche que les headers, sans le body. Utile pour vérifier les redirections, le type de contenu ou la mise en cache.

Sortie typique :

HTTP/2 200
content-type: text/html; charset=UTF-8
content-length: 1256
cache-control: max-age=604800

Si HEAD est bloqué

Certains serveurs ou WAF bloquent la méthode HEAD. Alternative pour voir les headers avec un GET :

curl -v -o /dev/null -sS https://example.com 2>&1 | grep -E "^< "

Mode verbose pour débugger TLS

curl -v https://example.com

L'option -v affiche tout le processus : résolution DNS, connexion TCP, handshake TLS, requête et réponse.

Extrait de sortie :

* Host example.com:443 was resolved.
* IPv4: 104.20.23.154, 172.66.147.243
*   Trying 104.20.23.154:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / id-ecPublicKey
*   subject: CN=example.com
*   issuer: C=US; O=SSL Corporation; CN=Cloudflare TLS Issuing ECC CA 3
* ALPN: server accepted h2
> GET / HTTP/2
< HTTP/2 200

Quatre lignes de cette sortie portent l'essentiel du diagnostic. was resolved confirme que le DNS a répondu ; Trying <ip>:443 que la connexion TCP est tentée ; la ligne SSL connection using donne la version TLS et la suite cryptographique réellement négociées ; ALPN: server accepted h2 indique que le serveur a accepté HTTP/2. Si la sortie s'arrête avant l'une de ces lignes, vous savez immédiatement à quelle couche la panne se situe. Les adresses IP et l'émetteur du certificat changent avec le temps, ne comparez que la structure.

Obtenir uniquement le code de statut HTTP

curl -s -o /dev/null -w "%{http_code}\n" https://example.com

Option	Effet
-s	Mode silencieux (pas de barre de progression)
-o /dev/null	Ignore le body
-w "%{http_code}\n"	Affiche uniquement le code de statut HTTP

Glissez pour voir

La combinaison des trois options est ce qui rend cette commande utilisable dans un script de supervision : elle n'écrit qu'un nombre sur la sortie standard, ce qui se compare directement dans un test. Retenez que %{http_code} renvoie le code de la dernière réponse reçue ; avec -L, vous obtiendrez donc le code final après redirections, pas le 301 initial.

Résultat : 200

Code 000 = échec avant HTTP

Si curl retourne 000, la connexion a échoué avant d'obtenir une réponse HTTP :

• Échec DNS : curl: (6) Could not resolve host
• Échec TCP : curl: (7) Failed to connect
• Échec TLS : curl: (35) SSL connect error

Utilisez curl -v pour diagnostiquer. Référence : curl --write-out.

Envoyer une requête POST avec JSON

Deux détails font échouer la plupart des premiers essais. Le header Content-Type: application/json est obligatoire : sans lui, curl annonce application/x-www-form-urlencoded et beaucoup d'API rejettent la requête avec un 400. Ensuite, les guillemets simples autour du JSON empêchent le shell d'interpréter les guillemets doubles internes. À noter que -d implique déjà POST, le -X POST est ici explicite pour la lisibilité.

curl -X POST \
  -H "Content-Type: application/json" \
  -d '{"username": "devops", "email": "devops@example.com"}' \
  https://httpbin.org/post

Option	Effet
-X POST	Utilise la méthode POST
-H "..."	Ajoute un header
-d '...'	Données à envoyer (body)

Glissez pour voir

Ignorer les erreurs de certificat (test uniquement)

Cette option sert à répondre à une question précise et limitée : le serveur répond-il, indépendamment du problème de certificat ? Elle permet donc de distinguer une panne applicative d'un problème de chaîne de confiance. Elle ne corrige rien et ne doit jamais sortir du contexte de diagnostic.

curl -k https://self-signed.example.com

Ne jamais utiliser -k en production

L'option -k (ou --insecure) désactive la vérification du certificat. Utile pour un test rapide, mais jamais en production : vous seriez vulnérable aux attaques man-in-the-middle.

Alternative propre : spécifier le CA

Pour tester un serveur avec un CA interne ou un certificat auto-signé de manière sécurisée :

# Spécifier le certificat CA
curl --cacert /path/to/ca.pem https://internal.example.com

# Ou un dossier de CAs
curl --capath /path/to/ca-certs/ https://internal.example.com

Cela valide le certificat contre votre CA, sans désactiver toute la sécurité TLS.

Suivre les redirections

curl -L https://example.com/redirect

L'option -L (ou --location) suit automatiquement les redirections 3xx. Deux effets à connaître : curl retire le header Authorization quand la redirection change de domaine, ce qui explique un 401 inattendu après un -L ; et le nombre de sauts est plafonné, réglable avec --max-redirs, ce qui protège des boucles de redirection. Sans -L, curl s'arrête au premier 3xx et affiche un corps vide, ce qui ressemble à tort à une panne.

Diagnostic HTTP : cas pratiques

L'API ne répond pas

Les trois étapes descendent la pile réseau dans l'ordre où les pannes se produisent. Ne les inversez pas : tester curl avant de vérifier le port vous fera interpréter un timeout comme un problème applicatif alors que le paquet n'arrive même pas. Chaque étape a un verdict binaire, ce qui permet de savoir quand s'arrêter.

1. Vérifier que le port est ouvert

   nc -zv api.example.com 443

   • Connection succeeded → port ouvert
   • Connection refused → service non démarré
   • Timeout → pare-feu ou réseau

2. Tester avec curl verbose

   curl -v https://api.example.com/health

   Examinez à quelle étape la connexion échoue.

3. Vérifier la résolution DNS

   dig api.example.com +short

   Pas de résultat ? Problème DNS.

Erreur 502 Bad Gateway

Le reverse proxy (Nginx, HAProxy) ne peut pas joindre le backend. Le point important : le proxy répond, donc le problème n'est ni le DNS ni le certificat. Le tableau ci-dessous va de la cause la plus fréquente à la plus rare, traitez-le dans cet ordre.

Cause probable	Vérification	Solution
Backend arrêté	systemctl status backend	Redémarrer le service
Mauvais port	Vérifier la config du proxy	Corriger le proxy_pass
Timeout trop court	Logs du proxy	Augmenter proxy_read_timeout

Glissez pour voir

Erreur 503 Service Unavailable

Le serveur est surchargé ou en maintenance. Contrairement au 502, le backend répond ici, mais il refuse de traiter la demande. Un 503 bien configuré s'accompagne d'un header Retry-After qui indique au client combien de temps attendre ; son absence est souvent le signe d'une saturation subie plutôt que d'une maintenance planifiée.

Cause probable	Vérification	Solution
Trop de requêtes	htop, logs applicatifs	Scaler horizontalement
Maintenance planifiée	Page de maintenance	Attendre
Pool de connexions épuisé	Logs backend	Augmenter les workers

Glissez pour voir

Problème de certificat TLS

La redirection 2>&1 est indispensable ici : curl écrit ses informations de diagnostic sur la sortie d'erreur, pas sur la sortie standard, et sans elle le filtre ne verrait rien passer. Les trois messages du tableau ci-dessous désignent trois problèmes très différents, alors qu'ils produisent tous le même symptôme côté navigateur, une page d'avertissement.

curl -v https://example.com 2>&1 | grep -i "ssl\|certificate"

Message	Cause	Solution
certificate has expired	Certificat expiré	Renouveler avec certbot
certificate verify failed	CA non reconnue	Installer le certificat CA
hostname mismatch	Domaine incorrect	Vérifier le CN/SAN du certificat

Glissez pour voir

Validation des acquis

Ces quatre exercices s'exécutent sur des services publics et donnent des résultats vérifiables immédiatement. Les deux premiers forment une paire : comparez les codes obtenus avec et sans -L pour voir concrètement ce que change le suivi de redirection. Si un exercice renvoie 000, votre poste passe probablement par un proxy sortant, adaptez la cible à un service interne.

1. Obtenir le code HTTP d'une URL

   curl -s -o /dev/null -w "%{http_code}" https://google.com

   Attendu : 301 (redirection vers www.google.com)

2. Suivre la redirection et obtenir le code final

   curl -sL -o /dev/null -w "%{http_code}" https://google.com

   Attendu : 200

3. Afficher les headers d'un site

   curl -I https://github.com

   Identifiez le Server, le Content-Type et les headers de sécurité.

4. Tester une API POST

   curl -X POST -H "Content-Type: application/json" \
     -d '{"test": "data"}' \
     https://httpbin.org/post

   Vérifiez que votre JSON apparaît dans la réponse.

Dépannage rapide

Ce tableau est ordonné du plus bas niveau vers le plus haut : les trois premières lignes concernent la connexion elle-même, les quatre suivantes une réponse HTTP bien reçue. C'est la distinction utile en incident. Tant que vous êtes dans les trois premières lignes, inutile de fouiller les journaux applicatifs, le serveur n'a jamais vu passer votre requête.

Symptôme	Cause probable	Solution
Connection refused	Service non démarré	Vérifier systemctl status
Connection timed out	Pare-feu ou réseau	Vérifier les règles firewall
SSL certificate problem	Certificat invalide/expiré	Renouveler ou ignorer avec -k (test)
curl: (6) Could not resolve	Problème DNS	Vérifier /etc/resolv.conf
401 Unauthorized	Token manquant/expiré	Vérifier l'authentification
403 Forbidden	Droits insuffisants	Vérifier les permissions/rôles
502 Bad Gateway	Backend inaccessible	Vérifier le service backend

Glissez pour voir

À retenir

• HTTP est un protocole requête/réponse : le client demande, le serveur répond
• Les codes 2xx = succès, 4xx = erreur client, 5xx = erreur serveur
• HTTPS = HTTP + TLS : chiffrement des données en transit
• curl -I affiche les headers, curl -v montre tout le processus
• Pour diagnostiquer : commencer par le code HTTP, puis les headers, puis les logs serveur
• 502 Bad Gateway = le proxy ne joint pas le backend
• 503 Service Unavailable = backend surchargé ou en maintenance

Testez vos connaissances

Le questionnaire ci-dessous porte uniquement sur ce qui vient d'être expliqué. Traitez-le sans revenir en arrière : les questions sur les codes de statut et sur la lecture d'une sortie curl -v sont celles qui révèlent le mieux les notions à relire.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

10 questions

10 min.

80% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

Ressources et références

Sujet	Source
HTTP sémantique	RFC 9110
Codes de statut HTTP	MDN HTTP Status Codes
TLS 1.3	RFC 8446
Ports officiels	IANA Service Name and Port Number Registry
curl --write-out	Everything curl
Let's Encrypt	letsencrypt.org

Glissez pour voir

FAQ : questions fréquentes sur HTTP et HTTPS

Ces réponses courtes traitent les questions qui reviennent le plus souvent après une première lecture, notamment sur le choix entre les codes de redirection et sur ce que TLS protège réellement. Elles complètent le guide sans le répéter.

Quelle est la différence entre HTTP et HTTPS ?

HTTP transporte les pages web en clair sur le port 80 : tout intermédiaire peut lire ou modifier le trafic. HTTPS, c'est HTTP dans TLS sur le port 443 : les échanges sont chiffrés, leur intégrité garantie et le serveur authentifié par un certificat. En 2026, HTTPS est la norme.

Que signifient les codes de statut 404, 403 et 500 ?

404 Not Found signifie que la ressource demandée n'existe pas. 403 Forbidden signifie que l'accès est interdit (droits insuffisants), la ressource existe mais le serveur refuse. 500 Internal Server Error signale un bug côté serveur. En résumé : 4xx = erreur du client, 5xx = erreur du serveur.

Quelle est la différence entre GET et POST ?

GET lit une ressource : les paramètres passent dans l'URL, la requête est idempotente et cacheable. POST envoie des données dans le corps de la requête ; l'opération n'est pas idempotente (rejouer un POST peut créer un doublon). On ne met jamais de données sensibles dans une URL GET.

Qu'est-ce que TLS, et faut-il encore parler de SSL ?

TLS (Transport Layer Security) est le protocole qui chiffre et authentifie les communications, notamment HTTPS. SSL est son ancêtre, mort et vulnérable : on ne devrait plus dire SSL pour désigner TLS. En 2026, TLS 1.3 est le standard, TLS 1.2 reste accepté, et TLS 1.0/1.1 sont dépréciés depuis 2021.

Qu'est-ce que HTTP/2 et HTTP/3 ?

HTTP/1.1 est textuel, une requête à la fois par connexion. HTTP/2 est binaire et multiplexe plusieurs requêtes sur une connexion TCP. HTTP/3 s'appuie sur QUIC en UDP (et non TCP) pour réduire la latence. Les trois restent du HTTP, chiffré par TLS en HTTPS.

301 ou 302 : quelle différence ?

301 Moved Permanently signale une redirection définitive : navigateurs et moteurs la mettent en cache et transfèrent le référencement. 302 Found est temporaire et n'est pas mise en cache. Pour un déménagement d'URL durable, utilisez 301 ; pour une bascule provisoire, 302.

401 ou 403 : quelle différence ?

401 Unauthorized signifie que le serveur ne sait pas qui vous êtes : authentification absente, token manquant ou expiré. 403 Forbidden signifie que le serveur vous a identifié mais refuse l'accès faute de droits. Réessayer sans changer d'identité ne lève ni l'un ni l'autre.

Faut-il passer un site en HTTPS ?

Oui. En 2026, HTTPS est la norme : les navigateurs marquent HTTP comme non sécurisé, et HTTPS protège la confidentialité et l'intégrité des échanges. Let's Encrypt fournit des certificats gratuits et automatisés via ACME. Le surcoût de TLS 1.3 est négligeable.

Prochaines étapes

Diagnostic TLS avec openssl Déboguez les erreurs SSL/TLS : chaîne incomplète, certificat expiré, SNI, versions

Protocoles email (SMTP, IMAP) Comprenez l'envoi et la réception d'emails, SPF, DKIM et DMARC

TCP vs UDP Plongez dans les protocoles de transport sous HTTP

DNS : résolution de noms Comprenez comment les noms de domaine deviennent des adresses IP

Commandes réseau de base Maîtrisez ip, ss, curl et les outils du quotidien

×

📖 Voir la documentation →