Expect: 100-continue — cet en-tête, ajouté par certains clients HTTP avant d’envoyer le corps d’une requête volumineuse, change la séquence d’échange avec un serveur. Plutôt que d’envoyer immédiatement le fichier complet, le client attend d’abord une réponse intermédiaire du serveur, portant le code 100, avant de transmettre le corps de la requête.
Sur l’API REST de WordPress, ce mécanisme prend tout son sens lors de l’envoi d’un média volumineux via l’endpoint /wp/v2/media : si le fichier dépasse la limite autorisée par la configuration du serveur, ou si le jeton d’authentification fourni dans les en-têtes est invalide, le serveur peut refuser la requête dès la réception des en-têtes, sans jamais avoir à recevoir le corps du fichier lui-même.
Le déroulement sans 100 Continue
Sans ce mécanisme, un client qui envoie un fichier de plusieurs centaines de mégaoctets transmet la totalité du fichier avant que le serveur ne puisse répondre quoi que ce soit, y compris un refus. Si l’authentification était invalide dès le départ, tout ce transfert réseau se révèle inutile, consommé pour rien, tant côté client que côté serveur qui doit malgré tout recevoir et généralement bufferiser une partie de ces données avant de les rejeter.
Le déroulement avec 100 Continue
- Le client envoie les en-têtes de la requête, avec
Expect: 100-continue, mais retient le corps. - Le serveur valide ce qu’il peut à partir des seuls en-têtes : authentification, taille annoncée via
Content-Length, type de contenu. - Si tout est valide, le serveur répond
100 Continue, et le client transmet alors le corps complet du fichier. - Si une validation échoue, le serveur répond directement avec le code d’erreur approprié, sans jamais recevoir le corps.
Ce que cela change pour un envoi rejeté
Un envoi refusé pour cause de jeton expiré ou de taille excessive n’occupe alors la bande passante que pour la taille des en-têtes de la requête, quelques centaines d’octets, au lieu de la taille complète du fichier. Sur une connexion mobile avec une bande passante limitée, ou sur un envoi automatisé en boucle par script, cette économie devient significative dès que les rejets ne sont pas exceptionnels.
Ce que WordPress ne contrôle pas directement
L’activation de ce mécanisme dépend entièrement du client qui effectue l’envoi (un navigateur, un outil en ligne de commande comme curl, une application mobile) et du serveur web en amont de PHP-FPM, qui doit gérer correctement la réponse intermédiaire avant de transmettre la requête à l’application. Côté WordPress lui-même, aucune configuration spécifique n’est nécessaire : le mécanisme se joue à un niveau inférieur de la pile réseau.
Vérifier que le mécanisme fonctionne
curl -v -X POST https://exemple.test/wp-json/wp/v2/media \
-H "Authorization: Bearer JETON_INVALIDE" \
-H "Expect: 100-continue" \
--data-binary @fichier-volumineux.mp4
Sur un serveur correctement configuré, la sortie détaillée de curl montre la réception d’une réponse d’erreur immédiatement après l’envoi des en-têtes, sans jamais transmettre le corps du fichier, ce qui confirme visuellement le fonctionnement du mécanisme.
Un cas d’usage concret : un script d’import automatisé
Sur un projet d’import automatisé de plusieurs centaines de fichiers vidéo vers la médiathèque via l’API REST, une partie des jetons d’authentification utilisés provenaient d’un lot généré la veille et expiraient parfois avant la fin du traitement complet. Sans le mécanisme 100 Continue, chaque échec d’authentification sur un fichier volumineux entraînait malgré tout l’envoi complet du fichier avant le rejet, ralentissant l’ensemble du script d’import de façon disproportionnée par rapport au nombre réel d’échecs.
Vérifier le comportement du serveur web en amont
Certains serveurs web, selon leur configuration, peuvent tout de même mettre en mémoire tampon l’intégralité du corps de la requête avant de la transmettre à PHP-FPM, ce qui annule en pratique le bénéfice du mécanisme même si le client l’a correctement initié. Une vérification via une capture réseau (avec un outil comme tcpdump ou l’onglet réseau d’un client HTTP graphique) permet de confirmer que le corps n’est effectivement transmis qu’après réception du code 100.
En résumé
Le code 100 Continue reste un détail invisible pour la plupart des utilisateurs de l’API REST de WordPress, mais il évite un gaspillage réseau concret lors de tentatives d’envoi de médias volumineux vouées à l’échec. Sa mise en œuvre ne dépend d’aucune configuration WordPress particulière, mais elle mérite d’être vérifiée côté client dès que des envois automatisés en volume sont en jeu.
