Est-il possible de mettre en cache les méthodes POST dans HTTP?)?
Avec une sémantique de mise en cache très simple: si les paramètres sont les mêmes (et l'URL est la même, bien sûr), alors c'est un hit. Est-ce possible? Conseillé?
Le RFC 2616 correspondant dans la section 9.5 (POST) permet la mise en cache de la réponse à un POST message, si vous utilisez les en-têtes appropriés.
Les réponses à cette méthode ne peuvent pas être mises en cache, sauf si la réponse inclut les champs d'en-tête Cache-Control ou Expires appropriés. Cependant, la réponse 303 (voir autre) peut être utilisée pour demander à l'agent d'utilisateur de récupérer une ressource pouvant être mise en cache.
Notez que le même RFC stipule explicitement dans la section 13 (Mise en cache dans HTTP) qu'un cache doit invalider l'entité correspondante après une demande POST ) .
Certaines méthodes HTTP DOIVENT obliger un cache à invalider une entité. Il s'agit de l'entité référencée par l'URI de la demande ou par les en-têtes Location ou Content-Location (le cas échéant). Ces méthodes sont:
- PUT - DELETE - POST
Je ne vois pas comment ces spécifications peuvent permettre une mise en cache significative.
Selon RFC 2616 Section 9.5:
"Les réponses à la méthode POST ne peuvent pas être mises en mémoire cache, SAUF SI la réponse inclut les champs d'en-tête Cache-Control ou Expires appropriés."
Donc, OUI, vous pouvez mettre en cache la réponse POST), mais uniquement si elle arrive avec les en-têtes appropriés. Dans la plupart des cas, vous ne souhaitez pas mettre la réponse en cache. Mais dans certains cas, comme ne sauvegardez aucune donnée sur le serveur - cela convient parfaitement.
Notez cependant que de nombreux navigateurs, y compris Firefox 3.0.10 actuel, ne mettront pas en cache la réponse POST quels que soient les en-têtes). IE se comporte plus intelligemment à cet égard.
Maintenant, je veux dissiper une certaine confusion concernant la RFC 2616 S. 13.10. La méthode POST sur un URI) n'invalide pas la ressource pour la mise en cache ", comme certains l'ont indiqué ici. Elle rend une version précédemment mise en cache de cet URI obsolète, même si ses en-têtes de contrôle de cache indiquaient la fraîcheur de durée plus longue.
Globalement:
En gros POST n'est pas une opération idempotente . Donc, vous ne pouvez pas l'utiliser pour la mise en cache. GET doit être une opération idempotente, il est donc couramment utilisé pour la mise en cache.
Veuillez vous reporter à la section 9.1 de la HTTP 1.1 RFC 2616 S. 9.1 .
Autre que la sémantique de la méthode GET:
La méthode POST elle-même est censée publier quelque chose sur une ressource. POST ne peut pas être mis en cache car, si vous faites quelque chose une fois contre deux fois, modifie chaque fois la ressource du serveur. Chaque demande est importante et doit être remise au serveur.
La méthode PUT elle-même est sémantiquement conçue pour mettre ou créer une ressource. C'est une opération idempotente, mais elle ne sera pas utilisée pour la mise en cache car un DELETE aurait pu se produire entre-temps.
La méthode DELETE elle-même est censée sémantiquement supprimer une ressource. C'est une opération idempotente, mais elle ne sera pas utilisée pour la mise en cache car un PUT aurait pu se produire entre-temps.
Concernant la mise en cache côté client:
Un navigateur Web transmettra toujours votre demande même si elle a reçu une réponse d'une précédente opération POST. Par exemple, vous pouvez envoyer des courriers électroniques avec gmail à quelques jours d'intervalle. Ils peuvent avoir le même objet et le même corps. , mais les deux emails doivent être envoyés.
En ce qui concerne la mise en cache du proxy:
Un serveur proxy HTTP qui transmet votre message au serveur ne mettrait jamais en cache autre chose qu'une requête GET ou une requête HEAD.
En ce qui concerne la mise en cache du serveur:
Par défaut, un serveur ne gère pas automatiquement une requête POST en vérifiant son cache. Toutefois, une requête POST peut être envoyée à votre application ou dans et vous pouvez avoir votre propre cache que vous lisez lorsque les paramètres sont les mêmes.
Invalider une ressource:
Le contrôle de HTTP 1.1 RFC 2616 S. 13.1 indique que la méthode POST doit invalider la ressource pour la mise en cache.
Si vous mettez en cache une réponse POST, celle-ci doit se faire dans la direction de l'application Web. C’est ce que l’on entend par "Les réponses à cette méthode ne sont pas masquables, sauf si la réponse inclut les champs d’en-tête Cache-Control ou Expires appropriés".
On peut supposer en toute sécurité que l'application, qui sait si les résultats d'un POST sont idempotents, décide de joindre ou non les en-têtes de contrôle de cache nécessaires et appropriés. Si des en-têtes suggérant que la mise en cache est autorisée sont présents, l'application vous indique que le POST est en réalité un super-GET; que l'utilisation de POST n'était nécessaire qu'en raison de la quantité de données inutiles et non pertinentes (pour l'utilisation de l'URI en tant que clé de cache) nécessaires à l'exécution de l'opération idempotent.
Les GET suivants peuvent être servis à partir de cache dans cette hypothèse.
Une application qui n'attache pas les en-têtes nécessaires et corrects pour différencier les réponses cachables et non cachables POST est responsable des résultats de mise en cache non valides.
Cela dit, chaque POST qui atteint le cache nécessite une validation à l'aide d'en-têtes conditionnels. Cela est nécessaire pour actualiser le contenu du cache afin d'éviter que les résultats d'un POST ne soient reflétés dans les réponses aux demandes qu'après l'expiration de la durée de vie de l'objet.
S'il s'agit de quelque chose qui ne modifie pas réellement les données de votre site, il devrait s'agir d'une demande GET. Même s'il s'agit d'un formulaire, vous pouvez toujours le définir comme une requête get. Bien que, comme le soulignent d’autres, vous pouvez mettre en cache les résultats d’un POST, cela n’a aucun sens sémantique, car un POST, par définition, modifie les données.
Mark Nottingham a analysé à quel moment il est possible de mettre en cache la réponse d’un POST. Notez que les requêtes suivantes qui souhaitent tirer parti de la mise en cache doivent être GET ou HEAD requêtes. Voir aussi httpbis
Les POST n'interviennent pas dans les représentations de l'état identifié, 99 fois sur 100. Cependant, il existe un cas où cela se produit; lorsque le serveur fait l'impossible pour dire que cette réponse POST) est une représentation de son URI, en définissant un en-tête Content-Location identique à celui de l'URI de la requête. POST est semblable à une réponse GET au même URI; elle peut être mise en cache et réutilisée - mais uniquement pour les futures demandes GET.
Bien sûr que c'est possible. Si vous souhaitez capturer les demandes POST envoyées à votre serveur et mettre en cache les données renvoyées pour les renvoyer ultérieurement - pas de problème.
La partie délicate vient en ce qui concerne "l'état". Comment décidez-vous que les données que vous souhaitez renvoyer à l'utilisateur doivent être identiques? Que se passe-t-il si ses cookies ont changé - cela change-t-il les données que vous souhaitez renvoyer?
Et si l’utilisateur faisait une demande à votre page d’accueil POST), et depuis la dernière fois, un autre utilisateur lui envoyait un message (utilisant un système de votre site.) identifiez cela comme un changement d'état et envoyez la nouvelle version de votre page d'accueil avec une notification à propos du message à l'utilisateur lors du prochain chargement de la page d'accueil, même si les paramètres POST sont identiques.