HTTP QUERY a sa RFC, mais presque aucune implémentation

HTTP a une nouvelle méthode pour la recherche. L'IETF a publié la RFC 10008, « The HTTP QUERY Method », en juin 2026 comme Proposed Standard (norme proposée) issu du groupe de travail httpbis. Trois mois plus tard, InfoQ rapportait en septembre 2026 qu'aucun projet n'avait annoncé un déploiement en production achevé.

La méthode a été rédigée par Julian Reschke, James M. Snell et Mike Bishop. Elle existe pour résoudre un problème que tout développeur d'API a contourné au moins une fois.

L'écart entre GET et POST

Une requête de recherche veut deux choses à la fois, et jusqu'ici HTTP obligeait à en choisir une.

GET est sûr, c'est-à-dire qu'il ne modifie rien sur le serveur. Il est idempotent, donc un client peut le rejouer sans conséquence, et il peut être mis en cache. Le hic, c'est que tout ce que vous demandez doit tenir dans l'URL. Les filtres longs butent sur les limites de longueur, ils atterrissent dans les journaux d'accès du serveur, et les structures imbriquées sont pénibles à encoder.

POST transporte un corps de n'importe quelle taille et forme. Mais il est défini comme ni sûr ni idempotent, donc les caches l'ignorent, les clients ne peuvent pas le rejouer sans risque, et tout ce qui se trouve entre les deux doit supposer qu'il a modifié quelque chose.

QUERY prend la moitié utile de chacun. La RFC le définit de sorte que « la cible de la requête traite le contenu joint de manière sûre et idempotente », puis réponde avec le résultat. Il est sûr, idempotent et peut être mis en cache, et il transporte un corps de requête. La RFC décrit le cas auquel il est destiné comme celui où « les données transmises sont trop volumineuses pour être encodées dans l'URI de la requête ».

Quelques règles l'accompagnent. Content-Type est obligatoire : « Les serveurs DOIVENT faire échouer la requête si le champ de requête Content-Type ... est absent ou incohérent avec le contenu de la requête. » Un serveur peut annoncer les formats de requête qu'il accepte via un en-tête Accept-Query. Les requêtes conditionnelles fonctionnent avec les en-têtes de validation HTTP standard.

Le cache est la partie à ne pas rater

Rendre cacheable une méthode dotée d'un corps est le problème difficile que la RFC doit résoudre. Un cache utilise normalement l'URL comme clé, et le sens d'une requête QUERY se trouve dans son corps.

La réponse de la RFC 10008 est que les clés de cache doivent intégrer le contenu complet de la requête ainsi que les métadonnées associées. Un cache qui ignorerait le corps servirait les résultats d'une recherche pour une recherche différente.

La RFC permet aussi à un serveur de renvoyer à la place une URL pour le résultat. Il peut attribuer une URI aux résultats et la désigner via Content-Location ou Location, ou utiliser une redirection 303 lorsque le traitement se fait indirectement. Cela donne aux clients un simple GET qu'ils peuvent partager, mettre en favori et mettre en cache normalement.

La sécurité joue ici dans les deux sens. Sortir une requête de l'URL pour la placer dans le corps est un progrès pour la vie privée, car la RFC note qu'une URI « a plus de chances d'être journalisée » que le contenu d'une requête. Mais l'échappatoire ci-dessus peut l'annuler. La spécification dit qu'une URI de résultat « DEVRAIT être choisie de sorte qu'elle n'inclue aucune portion sensible » de la requête d'origine. Les navigateurs ajoutent une contrainte de plus : QUERY n'est pas une méthode de la liste sûre (safelisted), donc les requêtes cross-origin déclenchent une requête préliminaire (preflight) CORS.

Qui l'a réellement livré

C'est là que la norme se distingue de la pratique. InfoQ présente l'état de la prise en charge comme un travail suivi, pas comme un travail achevé.

Projet	Statut, selon InfoQ
Crate Rust http	Prise en charge fusionnée
.NET	Ticket suivi
Axum	Ticket suivi
Quarkus	Ticket suivi
Bruno	Ticket suivi

Aucun d'eux n'affiche de date annoncée de déploiement en production. L'évaluation d'InfoQ est que « l'adoption réelle se mesurera probablement en années », parce qu'une méthode ne devient utilisable qu'une fois que les clients, les serveurs, les proxys et les caches sur le chemin la comprennent tous. InfoQ présente QUERY comme un ajout optionnel plutôt qu'un remplacement de GET ou POST.

Ce que cela signifie pour les développeurs

Ne réécrivez pas vos points de terminaison de recherche. Une requête QUERY qui rencontre un intermédiaire ignorant la méthode échoue, tout simplement. Vous ne contrôlez pas chaque saut entre votre client et votre serveur.

Le geste utile aujourd'hui est plus modeste : repérer lesquels de vos points de terminaison sont des QUERY déguisés. Un POST /search qui ne modifie rien sur le serveur est exactement le motif pour lequel cette méthode existe. Le savoir ne coûte rien aujourd'hui et fait de la migration à venir un renommage plutôt qu'une refonte.

Si vous maintenez une bibliothèque cliente, un framework serveur, un proxy ou un cache, le calcul est différent, car vous êtes le goulot d'étranglement que décrit le calendrier d'adoption. L'exigence de la RFC sur les clés de cache est la partie la plus susceptible d'être mal implémentée, et se tromper signifie servir les résultats de recherche d'un utilisateur à un autre.

Une mise en garde sur la promesse de sûreté. Le fait que QUERY soit sûr et idempotent est une promesse que votre gestionnaire doit tenir, pas quelque chose que la méthode impose. Rien n'empêche un serveur de modifier son état à l'intérieur d'un gestionnaire QUERY. S'il le fait, chaque nouvelle tentative et chaque cache sur le chemin deviennent un bogue difficile à trouver.