Méthode HTTP QUERY

Salut,
L’ouverture de ce topic correspond à de la pure curiosité, mais le questionnement part d’une situation concrète.

Mon questionnement vient d’une analyse SAST (checkmarx), qui me disait que mes méthodes POST de recherche, qui prenaient des paramètres complexes que je mettais dans le body (parce que j’avais envie !) n’avaient pas de protection CSRF. J’ai dit à checkmarx, après étude de la question : ben quoi, ça change pas l’état, laisse-moi tranquille ! Puis en réfléchissant, je me suis dit : n’est-ce pas moi qui ai tort ? quid de la sémantique ? Pourquoi utiliser un POST si je fais une simple requête derrière ?
Donc, recherche d’une meilleure méthode HTTP. Échec. Recherche d’articles sur le sujet. Trouvé notamment, ce qui fut source d’un immense espoir, un draft proposant une méthode QUERY pour HTTP, au sein du groupe de travail http de l’IETF.

Le problème semble donc bien connu et partagé : on a le GET quand on ne change pas l’état ; on a le POST (et PUT et PATCH, mais vous voyez) quand on change l’état. Mais quand on veut faire une requête qui ne modifie rien mais fait usage du body, on fait quoi ?

Sauf que je n’arrive pas vraiment à savoir ce qu’il en est. Je trouve cet article qui parle de l’arrivée dans le standard, mais en même temps le lien fourni parle d’un draft expiré. Par ailleurs, la documentation MDN ne mentionne pas ce verbe.

Ma questions, c’est : est-ce que ça vous parle comme questionnement ? Est-ce que vous savez si c’est toujours simplement un draft, si c’est dans le "standard track" ou si c’est dans le standard ? Est-ce qu’on s’en fiche de la sémantique et puisqu’un POST fait l’affaire on peut s’en satisfaire ? Curieux d’avoir votre avis

(Et, pour info concernant ma situation de départ : sur un de mes projets j’ai mis la protection CSRF sur tous les POST, pour que le SAST me laisse tranquille. Sur l’autre, je vais déclarer ce qu’il détecte comme faux positif, parce que le code sera plus simple et plus logique comme ça.)

Pour moi, si tu ne modifies rien, c’est que plusieurs requêtes identiques vont renvoyées le même résultats. Donc sémantiquement, tu devrais utiliser une requête PUT.

Après, dans la pratique, … C’est une toute autre histoire. Les règles ne sont pas vraiment respectées.

Pour ce qui est de QUERY. Je n’ai jamais vu cette méthode HTTP. Après, rien ne t’empêche de l’utiliser mais ça spécifique à ton projet, rien de plus qu’un brouillon. Elle n’a jamais été un standard.

Pour moi, si tu ne modifies rien, c’est que plusieurs requêtes identiques vont renvoyées le même résultats. Donc sémantiquement, tu devrais utiliser une requête PUT.

Pour le côté idempotent oui, mais pour moi PUT implique un changement d’état, comme POST, non ?

Effectivement, c’est possible, mais il me semble préférable de rester dans le standard. D’autant que comme tu dis les règles ne sont pas respectées, donc autant utiliser POST (ou PUT, en effet).

Ce qui m’a surpris et m’a motivé à poser la question ici, c’est l’article dont j’ai donné le lien et qui parle de l’arrivée dans le standard. C’est juste une erreur du coup, j’ai l’impression.

Je pense qu’ils ont sur-interprété. Beaucoup de draft de RFC n’aboutissent pas ensuite à une norme / modification d’un standard existant.

Le statut du brouillon:

https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-method-w-body/

PS: Pour ce qui est de PUT, oui, c’est elle est censée modifier une ressource.
Mais en même temps, si on l’appelle deux fois elle ne modifie pas de nouvelle ressource. Du coup, ça semble être me plus proche de ce que tu souhaites faire mais ça ne rentre effectivement pas tout à fait dans la définition sémantique de PUT.

Salut,

Ton dilemme est légit, surtout avec la sécurité web qui évolue tout le temps. Pour le draft QUERY, c’est vrai que c’est pas encore standard, mais ça résoudrait pas mal de soucis. Pour l’instant, si le POST marche sans souci et que t’as sécurisé tes méthodes, ça roule. Et ouais, déclarer un faux positif, c’est parfois la soluce la plus simple. Si t’as d’autres infos ou que ça bouge, partage ici !

A+