Requête classique ou flux continu ?

HTTP peut répondre en un seul bloc — ou envoyer les données au fil de l'eau. Découvre quand et pourquoi streamer.

Dans le web classique, une requête HTTP suit un schéma simple : tu envoies une demande, le serveur traite tout, puis répond d'un seul bloc. C'est parfait pour une page HTML ou un petit JSON. Mais que se passe-t-il quand la réponse prend du temps à se construire, ou qu'elle est volumineuse ?

Le streaming HTTP casse ce modèle. Au lieu d'attendre que tout soit prêt, le serveur envoie les données au fur et à mesure, par morceaux. Le client reçoit et affiche pendant que le serveur produit encore.

Trois mécanismes couvrent la quasi-totalité des besoins :

Chunked Transfer Encoding

Le mécanisme HTTP/1.1 qui permet d'envoyer une réponse sans connaître sa taille à l'avance.

Imagine que tu veux livrer une pizza, mais la boulangerie la prépare tranche par tranche. Au lieu d'attendre que tout soit prêt, tu livres chaque tranche dès qu'elle sort du four. Le Chunked Transfer Encoding fonctionne exactement ainsi.

Structure d'une réponse chunked sur le fil :

HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: text/plain

1a                 ← taille du chunk en hex (= 26 octets)
abcdefghijklmnopqrstuvwxyz
0d                 ← 13 octets
Hello, World!
0                  ← fin du flux

En PHP, activer le streaming est une question de buffers. Par défaut, PHP accumule la sortie avant de l'envoyer — il faut désactiver ce comportement :

// Désactiver la mise en tampon PHP
ob_implicit_flush(true);
if (ob_get_level() > 0) {
    ob_end_flush();
}

header('Content-Type: text/plain; charset=utf-8');
header('X-Accel-Buffering: no'); // désactive le buffer Nginx/FrankenPHP

for ($i = 1; $i <= 10; $i++) {
    echo "Étape $i traitée\n";
    flush();     // envoie immédiatement au client
    sleep(1);    // simule un traitement long
}

Avec Symfony, utilise StreamedResponse pour garder l'architecture propre :

use Symfony\Component\HttpFoundation\StreamedResponse;

return new StreamedResponse(function() {
    for ($i = 1; $i <= 10; $i++) {
        echo "data: {\"step\":$i}\n\n";
        ob_flush();
        flush();
        sleep(1);
    }
}, 200, [
    'Content-Type'  => 'text/plain',
    'Cache-Control' => 'no-cache',
    'X-Accel-Buffering' => 'no',
]);

Server-Sent Events — push du serveur vers le client

Un protocole dédié aux notifications en temps réel : notifications, logs live, tokens de LLM.

Le Chunked Encoding convient aux réponses longues à construire. Mais pour pousser des événements en continu — mises à jour, notifications, tokens d'un LLM — il existe un protocole dédié et standardisé : les Server-Sent Events.

Format d'un message SSE — texte brut, champs séparés par \n, message terminé par \n\n :

# Message simple
data: {"type":"metric","value":42}

# Message nommé avec ID (pour la reprise)
event: notification
data: Nouvelle commande #1024
id: 1024

Côté serveur PHP :

header('Content-Type: text/event-stream');
header('Cache-Control: no-cache');
header('X-Accel-Buffering: no');

$id = 0;
while (true) {
    $payload = json_encode(['id' => ++$id, 'v' => rand(0, 100)]);
    echo "id: $id\ndata: $payload\n\n";
    flush();
    sleep(1);
    if (connection_aborted()) break; // client déconnecté
}

Côté client JavaScript :

const source = new EventSource('/api/events');

source.onmessage = (e) => {
    const data = JSON.parse(e.data);
    console.log(`Reçu id=${data.id} v=${data.v}`);
};

// Écouter un event nommé
source.addEventListener('notification', (e) => {
    alert(e.data);
});

source.onerror = () => {
    // EventSource se reconnecte automatiquement
    console.warn('SSE: reconnexion...');
};

Streaming de fichiers et PDF

Télécharger un fichier volumineux sans saturer la RAM — readfile(), BinaryFileResponse et StreamedResponse.

Tu as une facture de 50 Mo à envoyer. L'erreur classique : charger l'intégralité du fichier en mémoire PHP, puis l'envoyer. Sur un serveur avec 128 Mo de RAM et dix téléchargements simultanés, c'est le plantage assuré.

// Charge TOUT le fichier en RAM
$content = file_get_contents($path);
echo $content;

// Lit et envoie par blocs de 8 Ko
readfile($path);

En PHP natif, pour forcer le téléchargement d'un PDF avec les bons en-têtes :

$path = '/var/storage/invoices/2024-001.pdf';

if (!is_file($path)) {
    http_response_code(404);
    exit;
}

header('Content-Type: application/pdf');
header('Content-Disposition: attachment; filename="facture-2024-001.pdf"');
header('Content-Length: ' . filesize($path));
header('Cache-Control: private, no-store');

readfile($path);

Avec Symfony, utilise les classes dédiées — elles gèrent automatiquement les en-têtes, les requêtes partielles (Range) et le streaming :

use Symfony\Component\HttpFoundation\BinaryFileResponse;
use Symfony\Component\HttpFoundation\ResponseHeaderBag;
use Symfony\Component\HttpFoundation\StreamedResponse;

// Fichier sur disque — la solution la plus simple
return new BinaryFileResponse(
    $path,
    200,
    [],
    true, // X-Sendfile si dispo
    ResponseHeaderBag::DISPOSITION_ATTACHMENT,
);

// Contenu généré à la volée (ex: export CSV, PDF généré par DomPDF)
return new StreamedResponse(function () use ($generator) {
    foreach ($generator->rows() as $row) {
        fputcsv(STDOUT, $row);
        ob_flush();
        flush();
    }
}, 200, [
    'Content-Type'        => 'text/csv; charset=utf-8',
    'Content-Disposition' => 'attachment; filename="export.csv"',
]);

Synthèse — choisir la bonne approche

Chunked, SSE, BinaryFileResponse, StreamedResponse : guide de décision pour chaque cas d'usage.

Trois mécanismes, trois cas d'usage. Le tableau ci-dessous est ton guide de décision.

Rappel des points clés à retenir :

• Chunked : désactive le buffer PHP (ob_implicit_flush(true)), appelle flush() après chaque écho, ajoute X-Accel-Buffering: no pour bypasser le proxy.
• SSE : Content-Type: text/event-stream, format data: ...\n\n, connection_aborted() pour détecter la déconnexion côté serveur.
• Fichiers : BinaryFileResponse pour les fichiers disque, StreamedResponse pour la génération à la volée. Jamais file_get_contents() pour de gros fichiers.
• Sécurité fichiers : valide toujours le chemin avec realpath() avant de le servir.