En juin 2026, l’IETF a publié le RFC 10008 et officialisé la méthode QUERY, pensée pour combler un manque dans le protocole HTTP : envoyer une requête volumineuse dans le corps du message, comme avec POST, tout en conservant les garanties de GET. Voici l’essentiel à savoir sur cette nouvelle méthode.

GET ou POST, il fallait choisir : QUERY réconcilie les deux

Pour interroger un service, un développeur a le choix entre deux méthodes, chacune avec son défaut.

• est sûre, idempotente et cacheable, mais les paramètres voyagent dans l’URL. Sauf que la taille d’une URL n’est pas garantie d’un bout à l’autre de la chaîne (le RFC rappelle que la recommandation est de supporter au moins 8000 octets). Encoder un filtre complexe dans une query string devient vite illisible, et les URL finissent dans les journaux, l’historique du navigateur et les favoris.

• accepte un corps de requête volumineux, mais rien, dans le protocole, n’indique que l’opération est sûre et en lecture seule. Résultat, les caches ne peuvent pas s’en servir et un rejeu automatique après une coupure réseau devient risqué.

Idempotente, sûre… Deux mots qui méritent une explication rapide, parce que tout repose dessus.

• Sûre : la requête ne demande aucune modification de la ressource. Elle lit, elle ne touche à rien. Le serveur a bien le droit de travailler en coulisses (journaliser, taper dans une base, écrire un résultat temporaire), mais l’état visible de la ressource ciblée reste inchangé.
• Idempotente : envoyer la requête une fois ou dix fois de suite produit le même effet sur le serveur. C’est la garantie qui permet à un client, un proxy ou un CDN de rejouer automatiquement une requête après une coupure réseau, sans se demander s’il vient de créer dix commandes au lieu d’une.

La méthode GET est donc utilisée pour récupérer une ressource (une image, une feuille de style CSS, etc…), notamment lorsqu’il est question de charger une page web. Par ailleurs, d’innombrables API de recherche utilisent donc pour de simples consultations, en perdant au passage la mise en cache HTTP et les retries sécurisés. C’est là qu’intervient .

La méthode transporte le contenu de la requête dans le corps du message, comme , mais elle est explicitement sûre et idempotente, comme . Le tableau de synthèse du RFC résume la logique : là où est potentiellement non sûre et non idempotente, coche les deux cases, ce qui réautorise le cache et le rejeu automatique en cas de problème. La méthode a d’ailleurs été enregistrée par l’IANA dans le registre officiel des méthodes HTTP.

En pratique, comment fonctionne une requête HTTP QUERY ?

Un serveur qui reçoit une requête traite le contenu et renvoie le résultat dans un . Le RFC ajoute deux mécanismes. D’abord un nouvel en-tête de réponse, , ce qui permet d’indiquer ce que l’on accepte au niveau de la requête , notamment quels formats (le RFC cite en exemple des types de média comme , ou ). Ensuite, le serveur peut renvoyer un en-tête pointant vers une ressource équivalente accessible par un simple , de sorte qu’une requête peut être mise en favori, partagée ou rejouée sans renvoyer le corps à chaque fois.

Voici à quoi ressemble une requête QUERY :

Pour ceux qui veulent réviser les bases avant d’aller plus loin, notre article dédié au fonctionnement du protocole HTTP revient sur les méthodes, les codes de retour et les versions du protocole.

Sécurité et cache : ce que QUERY change

Au-delà du confort pour les développeurs, a des effets directs sur l’exploitation et la sécurité, dans les deux sens.

Côté bénéfices, trois points ressortent.

• Le cache redevient possible pour des recherches complexes. Parce qu’elle est sûre et idempotente, une réponse à peut être mise en cache par un CDN ou un reverse proxy, ce que n’autorisait pas. Le RFC précise toutefois que la clé de cache doit intégrer le corps de la requête, ce qui rend l’opération plus coûteuse qu’un simple cache de .
• Les rejeux deviennent sûrs. En cas de coupure, un client ou un intermédiaire peut relancer la requête sans craindre un effet de bord, puisque la méthode est idempotente par définition.
• La confidentialité s’améliore. Les filtres voyagent dans le corps et non dans l’URL. Le RFC souligne, dans ses considérations de sécurité, que l’URL est plus susceptible d’être journalisée qu’un corps de requête, ce qui fait de un choix pertinent quand la requête contient des données sensibles.

Côté vigilance, la nouveauté impose un travail de revue que les équipes sécurité auraient tort de négliger.

• n’est pas une méthode CORS “safelisted”. Une requête cross-origin déclenchera donc un preflight, c’est écrit noir sur blanc dans les considérations de sécurité du RFC (qui renvoie à la spécification Fetch).
• Vos pare-feux applicatifs (WAF) et les passerelles d’API sont certainement configurés de façon à ignorer la méthode QUERY (car elle n’est pas dans la liste des méthodes autorisées). Un filtre trop strict la rejettera, un filtre trop permissif pourrait la laisser contourner une règle pensée pour . Il y aura surement un ajustement de la configuration à prévoir.

Comme à chaque nouveauté dans un protocole, reste la question de l’adoption. Ceci n’est pas un draft RFC, c’est officiel, mais il faut désormais l’implémenter. La présence de Cloudflare et d’Akamai parmi les auteurs de cette nouveauté laisse penser que le support arrivera vite côté CDN. Pour le reste, le chemin sera surement plus long, y compris au niveau des navigateurs Web.

La norme est publiée, mais votre pile logicielle ne la comprendra pas pour autant dès demain : ne remplacera ni ni du jour au lendemain, des millions d’applications reposant sur les méthodes existantes.

Pour en savoir plus, voici des liens utiles :

• RFC 10008 – The HTTP QUERY Method (IETF, juin 2026)
• Fiche du RFC 10008 sur l’IETF Datatracker