Le fonctionnement du web

Symfony cache beaucoup de choses : on reçoit un objet Request, on renvoie une Response, et le reste semble magique. Mais le jour où un cookie de session disparaît, où un site refuse d'appeler ton API, où l'adresse IP enregistrée est toujours la même, ou où un changement de serveur « ne marche que pour certains », il faut savoir ce qui circule entre le navigateur et le serveur.

Cette fiche suit le trajet d'une requête, étape par étape. Chaque étape est une source de bugs connue, et souvent de failles.

1.Le trajet d'une requête

Une adresse web (une URL) se découpe en morceaux, et chacun sert à une étape différente :

<?php

declare(strict_types=1);

// Les morceaux d'une adresse, tels que PHP les découpe
$url = 'https://shop.example.com:8443/produits/clavier?couleur=noir&page=2#avis';

foreach (parse_url($url) as $part => $value) {
    printf("%-8s %s\n", $part, $value);
}

parse_str(parse_url($url, PHP_URL_QUERY), $query);
echo "\nParamètres de la requête : ", json_encode($query), "\n";

scheme   https
host     shop.example.com
port     8443
path     /produits/clavier
query    couleur=noir&page=2
fragment avis

Paramètres de la requête : {"couleur":"noir","page":"2"}

Quand l'utilisateur valide cette adresse, voici ce qui se passe :

1. Le DNS traduit le nom shop.example.com en adresse IP, l'adresse numérique du serveur (section 2).
2. Une connexion s'ouvre vers cette adresse, sur le port 443 (le port par défaut de HTTPS, ici remplacé par 8443).
3. TLS chiffre la connexion et vérifie l'identité du serveur grâce à son certificat (section 5).
4. Le navigateur envoie la requête HTTP : la méthode, le chemin /produits/clavier, la requête ?couleur=noir&page=2, les en-têtes et les cookies (section 3).
5. Côté serveur, un reverse proxy comme nginx reçoit la requête et la transmet à PHP-FPM, qui exécute Symfony (section 6).
6. Symfony construit l'objet Request, trouve la route, appelle le contrôleur et renvoie une Response.
7. Le navigateur reçoit la réponse et l'affiche. Puis il recommence pour chaque image, feuille de style et script de la page.

Le fragment (#avis) n'est jamais envoyé au serveur : il ne sert qu'au navigateur, pour se placer dans la page. C'est pour cela qu'il n'apparaît jamais dans l'objet Request.

2.Le DNS : l'annuaire du web

Le DNS (Domain Name System) traduit un nom de domaine en adresse IP. Chaque domaine publie des enregistrements :

; Les enregistrements DNS d'un domaine (adresses de documentation, fictives)
; nom                  TTL    type   valeur
shop.example.com.      3600   A      203.0.113.10          ; adresse IPv4
shop.example.com.      3600   AAAA   2001:db8::10          ; adresse IPv6
www.shop.example.com.  3600   CNAME  shop.example.com.     ; un alias vers un autre nom
shop.example.com.      3600   MX     10 mail.example.com.  ; où livrer les e-mails
shop.example.com.      3600   TXT    "v=spf1 include:_spf.example.com -all"
                                                           ; texte libre : SPF, vérifications…

• A et AAAA : l'adresse IPv4 et l'adresse IPv6 du serveur.
• CNAME : un alias, qui renvoie vers un autre nom. Il ne peut pas être posé sur le domaine racine lui-même (example.com).
• MX : le serveur qui reçoit les e-mails du domaine.
• TXT : du texte libre, utilisé pour prouver qu'on possède le domaine ou pour lutter contre l'usurpation d'e-mails (SPF, DKIM, DMARC).

Pour trouver la réponse, le navigateur interroge d'abord son cache, puis celui du système, puis un résolveur (celui du fournisseur d'accès, ou un résolveur public). Si le résolveur ne la connaît pas, il remonte une chaîne de serveurs : la racine, puis le serveur de .com, puis le serveur qui fait autorité pour example.com.

3.HTTP : une requête, une réponse

HTTP est un échange très simple : le client envoie une requête, le serveur renvoie une réponse. En HTTP/1.1, les deux sont du texte lisible. Voici l'ajout d'un article au panier :

POST /panier/articles HTTP/1.1
Host: shop.example.com
Content-Type: application/json
Accept: application/json
Cookie: PHPSESSID=8f2c1e0b7d6a4c39
Content-Length: 34

{"productId": 42, "quantity": 2}

HTTP/1.1 201 Created
Content-Type: application/json
Location: /panier/articles/7
Cache-Control: no-store
Set-Cookie: PHPSESSID=8f2c1e0b7d6a4c39; Path=/; Secure; HttpOnly; SameSite=Lax

{"id": 7, "productId": 42, "quantity": 2}

Chaque message a la même forme : une première ligne (la méthode et le chemin, ou le code de statut), des en-têtes (Nom: valeur), une ligne vide, puis un corps facultatif. HTTP/2 et HTTP/3 transportent exactement les mêmes informations, mais en binaire et plus efficacement : plusieurs requêtes partagent une seule connexion. Pour toi, côté Symfony, rien ne change.

Voici la même requête, vue depuis Symfony :

<?php

declare(strict_types=1);

namespace App\Controller;

use App\Dto\AddToCart;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\JsonResponse;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\HttpKernel\Attribute\MapRequestPayload;
use Symfony\Component\Routing\Attribute\Route;

final class CartController extends AbstractController
{
    // La même requête, vue par Symfony : la méthode, le chemin, le corps JSON
    #[Route('/panier/articles', methods: ['POST'])]
    public function add(#[MapRequestPayload] AddToCart $payload): JsonResponse
    {
        // $payload est déjà désérialisé ET validé : sinon Symfony répond 422 tout seul
        $item = [
            'id' => 7,
            'productId' => $payload->productId,
            'quantity' => $payload->quantity,
        ];

        return $this->json($item, Response::HTTP_CREATED, [
            'Location' => '/panier/articles/7',
        ]);
    }
}

Les méthodes

• Une méthode sûre ne modifie rien. Un navigateur, un robot d'indexation ou un outil de préchargement peut appeler un GET à tout moment : un lien « supprimer » en GET finira par être cliqué par un robot.
• Une méthode idempotente donne le même résultat si on la répète : supprimer deux fois la même ressource la laisse supprimée. C'est ce qui permet de rejouer une requête sans danger après une coupure réseau. Un POST répété, lui, peut créer deux commandes.

Les codes de statut

La différence entre 401 et 403 revient souvent : 401 veut dire « je ne sais pas qui tu es, connecte-toi », 403 veut dire « je sais qui tu es, et tu n'as pas le droit ». Et une erreur 502 ou 504 renvoyée par nginx indique presque toujours que PHP-FPM est arrêté, saturé ou trop lent.

4.Cookies et sessions : se souvenir de l'utilisateur

HTTP est sans état : chaque requête est indépendante, et le serveur ne se souvient pas de la précédente. Pour savoir que la requête vient du même utilisateur, il faut une information qui voyage avec chaque requête : un cookie.

1. Le serveur envoie l'en-tête Set-Cookie (voir la réponse de la section 3).
2. Le navigateur le garde, et le renvoie automatiquement dans l'en-tête Cookie de chaque requête vers ce site.
3. Une session s'appuie sur ce mécanisme : le cookie ne contient qu'un identifiant au hasard (PHPSESSID), et les données (l'utilisateur connecté, le panier) restent sur le serveur.

Les attributs d'un cookie décident où et comment il voyage :

• Secure : envoyé seulement en HTTPS.
• HttpOnly : invisible pour JavaScript. Un script injecté dans la page (une faille XSS, fiche 10) ne peut pas le lire.
• SameSite=Lax : pas envoyé quand un autre site soumet un formulaire vers le tien. C'est une protection importante contre le CSRF (fiche 10). Strict va plus loin, None l'envoie partout et exige Secure.
• Max-Age ou Expires : sa durée de vie. Sans eux, il disparaît à la fermeture du navigateur.

# config/packages/framework.yaml : le cookie de session
framework:
    session:
        cookie_secure: auto      # Secure dès que la requête arrive en HTTPS
        cookie_httponly: true    # invisible pour JavaScript
        cookie_samesite: lax     # pas envoyé par les formulaires POST venus d'un autre site

5.HTTPS et TLS

HTTPS, c'est HTTP transporté dans une connexion TLS. TLS apporte trois garanties :

1. La confidentialité : personne sur le chemin (le Wi-Fi du café, le fournisseur d'accès) ne peut lire les échanges.
2. L'intégrité : personne ne peut les modifier en route, par exemple pour injecter une publicité ou un script.
3. L'authentification du serveur : le certificat prouve que le serveur contrôle bien le nom de domaine.

Un certificat est signé par une autorité de certification que le navigateur connaît. Let's Encrypt en délivre gratuitement, avec une durée de vie courte, et des outils les renouvellent automatiquement. Le cadenas veut dire « la connexion avec ce domaine est protégée ». Il ne veut pas dire « ce site est honnête » : un site d'hameçonnage a aussi son certificat.

Une fois le site en HTTPS, l'en-tête HSTS demande au navigateur de ne plus jamais l'appeler en HTTP simple, même si l'utilisateur tape http:// :

HTTP/1.1 200 OK
Strict-Transport-Security: max-age=31536000; includeSubDomains

6.Proxys, répartiteurs de charge et CDN

Entre le navigateur et Symfony, la requête traverse souvent plusieurs intermédiaires :

• Un reverse proxy (nginx, Caddy, Traefik) reçoit les requêtes à la place de l'application. Il sert les fichiers statiques, gère souvent HTTPS, et transmet le reste à PHP-FPM.
• Un répartiteur de charge (load balancer) distribue les requêtes entre plusieurs serveurs identiques. Conséquence directe : les sessions ne peuvent plus être stockées dans des fichiers locaux, sinon l'utilisateur perd sa session en changeant de serveur. On les met dans Redis ou en base.
• Un CDN (Content Delivery Network) garde des copies des fichiers dans des serveurs proches des utilisateurs, partout dans le monde.
• Un proxy tout court (ou forward proxy) est placé du côté du client, par exemple celui d'une entreprise qui filtre la navigation de ses salariés.

Problème : pour Symfony, la requête vient maintenant de nginx, plus de l'utilisateur. L'adresse IP vue est celle du proxy, et le protocole est HTTP alors que l'utilisateur est en HTTPS. Les proxys transmettent les vraies valeurs dans les en-têtes X-Forwarded-*, mais Symfony ne les lit que si on le lui demande :

# config/packages/framework.yaml : faire confiance aux en-têtes X-Forwarded-*
# SEULEMENT quand ils viennent de nos propres proxys
framework:
    trusted_proxies: '10.0.0.0/8'   # le réseau privé où se trouvent nos proxys
    trusted_headers:
        - 'x-forwarded-for'
        - 'x-forwarded-proto'
        - 'x-forwarded-port'
        - 'x-forwarded-host'

7.Les API REST

Une API permet à un programme (une application mobile, un front JavaScript, un autre serveur) d'utiliser ton application. REST est un style de conception qui s'appuie entièrement sur HTTP : les ressources sont des noms dans l'URL, et les méthodes HTTP sont les verbes.

1. Des noms, pas des verbes : /orders, pas /getOrders. La méthode HTTP dit déjà ce qu'on fait.
2. Les bons codes de statut : un client d'API lit le code avant le corps. Une erreur renvoyée avec un code 200 casse tous les outils.
3. Des erreurs dans un format standard, les problem details (RFC 9457), avec le type de contenu application/problem+json :

{
    "type": "https://shop.example.com/errors/out-of-stock",
    "title": "Stock insuffisant",
    "status": 409,
    "detail": "Il ne reste que 1 exemplaire de « Souris », 2 demandés.",
    "instance": "/panier/articles"
}

4. Une pagination pour toute liste qui peut grandir (fiche 7, section 11).
5. Un versionnage (/v1/orders, ou un en-tête) dès qu'une API est utilisée par des clients que tu ne contrôles pas : tu ne peux pas les obliger à se mettre à jour le jour où tu changes un champ.

Dans Symfony, #[MapRequestPayload] transforme le corps JSON en objet et le valide (section 3), et $this->json() produit la réponse. Pour une API riche, API Platform génère une grande partie de ce travail.

8.CORS : quand le navigateur bloque ton API

Ton front est sur https://app.example.com, ton API sur https://api.example.com. Le code JavaScript du front appelle l'API, et le navigateur bloque la réponse, avec une erreur « CORS » dans la console.

C'est la politique de même origine : par défaut, un script ne peut lire que les réponses de sa propre origine, c'est-à-dire du même protocole, du même domaine et du même port. Sans elle, n'importe quel site que tu visites pourrait lire tes e-mails dans ton webmail, avec tes cookies. CORS (Cross-Origin Resource Sharing) permet au serveur d'autoriser explicitement certaines autres origines :

# 1. Le navigateur, sur https://app.example.com, demande d'abord la permission (« preflight »)
OPTIONS /api/orders HTTP/1.1
Host: api.example.com
Origin: https://app.example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type

# 2. L'API répond quelles origines, méthodes et en-têtes elle accepte
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: content-type
Access-Control-Max-Age: 3600

# 3. Seulement ensuite, le navigateur envoie la vraie requête POST

Dans Symfony, le bundle NelmioCorsBundle gère ces en-têtes à partir d'une configuration, plutôt que de les écrire à la main dans chaque contrôleur.

Pièges fréquents

Checklist

• Chaque route utilise la méthode HTTP qui correspond à ce qu'elle fait, et aucune action ne modifie des données en GET.
• Chaque réponse a le bon code de statut, y compris en cas d'erreur.
• Le site est entièrement en HTTPS, avec HSTS une fois tous les sous-domaines vérifiés.
• Le cookie de session est Secure, HttpOnly et SameSite=Lax.
• Les sessions sont partagées entre serveurs s'il y en a plusieurs.
• trusted_proxies ne contient que mes propres proxys.
• L'API renvoie des erreurs au format problem details, et ses listes sont paginées.
• CORS n'autorise que les origines nécessaires, et l'API vérifie quand même les droits.

Conseils

1. Ouvre l'onglet Réseau des outils de développement de ton navigateur sur tes propres pages. Clique sur une requête : tu y retrouves la méthode, le statut, les en-têtes et les cookies de cette fiche. C'est le meilleur outil pour comprendre un bug HTTP.
2. Utilise le profiler de Symfony : son panneau « Request / Response » montre ce que Symfony a reçu et renvoyé, y compris les en-têtes ajoutés par les proxys.
3. Lis les messages d'erreur CORS en entier. La console du navigateur dit précisément quel en-tête manque ou quelle origine a été refusée.
4. Commence petit avec les API. Quelques routes bien nommées, avec les bons codes et des erreurs claires, valent mieux qu'un grand cadre théorique.

Documentation officielle

• Symfony et les bases de HTTP
• HTTP Semantics (RFC 9110), la norme de référence, et la documentation HTTP de MDN, plus accessible
• Les sessions dans Symfony
• Symfony derrière un proxy ou un répartiteur de charge
• Mapper le corps d'une requête avec #[MapRequestPayload]
• Problem Details for HTTP APIs (RFC 9457)
• Le fonctionnement de Let's Encrypt
• CORS sur MDN