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

• 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…

• 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

# 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).

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

Une requête HTTP contient :

É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

Une réponse HTTP contient :

É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.

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.

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	—

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.

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.

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

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).

Forward Secrecy

Grâce à ECDHE, même si la clé privée du serveur est compromise plus tard, les sessions passées restent protégées. C’est le Perfect Forward Secrecy (PFS).

Certificats gratuits avec Let's Encrypt

Let’s Encrypt fournit des certificats TLS gratuits et automatisables. Plus d’excuse pour rester en HTTP !

Ce que HTTPS chiffre (et ne chiffre pas)

Chiffré : tous les headers HTTP et le body (URL path, cookies, données)

Visible : adresse IP de destination, et par défaut le SNI (Server Name Indication = nom de domaine demandé). ECH (Encrypted Client Hello) résout ce dernier point mais n’est pas encore généralisé.

Headers HTTP essentiels (DevOps)

En diagnostic, vous manipulerez souvent ces headers :

Headers de requête

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

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)

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 :

* Connected to example.com (93.184.216.34) port 443
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* Server certificate:
*   subject: CN=www.example.org
*   issuer: C=US, O=DigiCert Inc
*   SSL certificate verify ok.
> GET / HTTP/2
< HTTP/2 200

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

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

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)

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.

Diagnostic HTTP : cas pratiques

L’API ne répond pas

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.

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.

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

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

Testez vos connaissances avec ces exercices :

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

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

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

Prochaines étapes

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 →