Est-il possible de cache méthodes POST en HTTP?

Très simples de mise en cache de la sémantique: si les paramètres sont les mêmes (et l'URL est la même, bien sûr), puis c'est un succès. Est-ce possible? Recommandé?

InformationsquelleAutor flybywire | 2009-03-09

93

Le correspondant La RFC 2616 dans l'article 9.5 de la (POST) permet la mise en cache de la réponse à un message, si vous utilisez les en-têtes appropriés.

Les réponses à cette méthode ne sont pas mis en cache, à moins que la réponse
prévoit des mesures de Contrôle du Cache ou de l'Expiration de champs d'en-tête. Cependant,
303 (Voir d'Autres) réponse peut être utilisée pour diriger l'utilisateur de l'agent de
récupérer un cache de ressources.

Noter que la même RFC précise de manière explicite dans l'article 13 (mise en Cache HTTP) qu'un cache doit invalidation de l'entité après un POST demande.
Une des méthodes HTTP DEVEZ provoquer un
cache pour invalider une entité. C'est
soit l'entité visée par la
URI de demande, ou par l'Emplacement ou
Contenu de l'Emplacement des en-têtes (si présent).
Ces méthodes sont:
```
  - PUT
  - DELETE
  - POST
```
Il n'est pas clair pour moi comment ces caractéristiques peuvent permettre de sens de la mise en cache.
- Cette section s'applique à un intermédiaire cache (comme une mise en cache du serveur proxy), pas le serveur d'origine.
- Vrai, mais ils peuvent être interprétés dans ce contexte (et ils font sens).
- Le serveur d'origine est un courtier entre HTTP et l'application qui gère les requêtes POST. L'application est au-delà de la HTTP limite et il peut faire ce qu'il veut. Si la mise en cache de sens que pour un POSTE spécifique de demande de cache, autant que l'OS peut mettre en cache disque demandes.
- C'est ce que je voulais dire, que l'application en cours d'exécution sur le serveur d'origine n'est pas lié par la HTTP restrictions sur la mise en cache.
- Diomidis, votre relevé que la mise en cache des requêtes POST ne serait pas HTTP, est faux. Veuillez voir le redémarrage de la réponse pour plus de détails. Ce n'est pas très utile d'avoir la mauvaise réponse se présenter au top, mais c'est la façon dont fonctionne la démocratie. Si vous acceptez le redémarrage, il serait agréable si vous avez corrigé votre réponse.
- Eugene, pouvons-nous accepter qu'un) POST devrait invalider le cache d'entité (par section 13.10), de sorte que, par exemple, une ultérieure OBTENIR doit aller chercher un fersh copie et b) que les POSTES peuvent être mis en cache (par section 9.5), de sorte que, par exemple, le billet suivant, peuvent recevoir la même réponse?
- Diomidis, nous pouvons probablement d'accord sur beaucoup de choses, mais j'ai explicitement critiqué le "si vous le cache, il ne serait pas HTTP déclaration, comme la spécification HTTP, dit (bien que formulée dans l'inverse), mise en mémoire cache est OK, le cas échéant en-têtes sont utilisés".
- Eugene, j'ai modifié l'entrée comme je l'ai suggéré. Je ne peux cependant voir comment cela pourrait fonctionner dans la pratique.
- Grâce Diomidis, je l'apprécie.
- Cela doit être clarifié par HTTPbis; voir mnot.net/blog/2012/09/24/caching_POST pour un résumé.
InformationsquelleAutor Diomidis Spinellis
65

Selon la RFC 2616 l'Article 9.5:

"Réponses à la méthode POST ne sont pas
mis en cache, à MOINS que la réponse
prévoit des mesures de Contrôle du Cache ou
L'expiration de champs d'en-tête."

Donc, OUI, vous pouvez mettre en cache demande POST de réponse, mais seulement si elle arrive avec des en-têtes appropriés. Dans la plupart des cas, vous ne voulez pas mettre en cache la réponse. Mais dans certains cas - comme si vous n'êtes pas enregistrer les données sur le serveur c'est tout à fait approprié.

Noter, cependant, beaucoup de navigateurs, y compris Firefox 3.0.10, ne cache de la réponse POST indépendamment des en-têtes. IE se comporte plus intelligemment à cet égard.

Maintenant, je veux dissiper une certaine confusion en ce qui concerne la RFC 2616 S. 13.10. Méthode POST sur un URI n'est pas "invalider les ressources pour la mise en cache", comme certains l'ont dit ici. Il fait déjà un version en cache d'URI rassis, même si son cache-têtes de contrôle indiqué la fraîcheur de longue durée.
- +1 reBoot, merci pour l'explication des en-têtes de problème et aussi la correction de la des déclarations erronées concernant la 13.10. Surprenant les mauvaises réponses reçues afin de des voix.
- Quelle est la différence entre "invalider les ressources pour la mise en cache" et "faire une version en cache de l'URI périmé"? Dites-vous que le serveur est autorisé à cache un POST de réponse, mais les clients ne le peut pas?
- "faire une version en cache de l'URI vicié" s'applique lorsque vous utilisez le même URI pour GET et POST demandes. Si vous êtes un cache assis entre le client et le serveur, à vous de voir GET /foo et vous mettre en cache la réponse. Ensuite, vous voyez POST /foo alors vous êtes obligatoire pour invalider la réponse en cache de GET /foo même si le POST réponse ne comprennent pas les en-têtes parce qu'ils sont de la même URI, donc la prochaine GET /foo aurez à revalider même si l'original des en-têtes indiqué le cache serait toujours en direct (si vous ne l'avait pas vu l' POST /foo demande)
InformationsquelleAutor
33

Globale:

Fondamentalement La POSTE n'est pas une opération équipotente. Vous ne pouvez donc pas l'utiliser pour la mise en cache. OBTENEZ devrait être un idempotent de l'opération, de sorte qu'il est couramment utilisé pour la mise en cache.

Veuillez voir la section 9.1 de la HTTP 1.1 RFC 2616 S. 9.1.

Autre que de se de la méthode de la sémantique:

La méthode POST en lui-même est sémantiquement destinée à poster quelque chose à une ressource. POSTE ne peut pas être mis en cache, car si vous faites quelque chose une fois que vs vs deux fois par trois fois, puis vous modifiez la ressource du serveur à chaque fois. Chaque demande de questions et devrait être livré au serveur.

La méthode PUT lui-même est sémantiquement destiné à mettre ou de créer une ressource. C'est un idempotent de l'opération, mais il ne sera pas utilisé pour la mise en cache, car une SUPPRESSION pourrait avoir eu lieu dans l'intervalle.

La SUPPRESSION de la méthode elle-même est sémantiquement destinée à supprimer une ressource. C'est un idempotent de l'opération, mais il ne sera pas utilisé pour la mise en cache à cause d'un PUT pourrait avoir eu lieu dans l'intervalle.

Concernant la mise en cache côté client:

Un navigateur web va toujours de l'avant de votre demande, même si elle a une réponse d'un POST précédent l'opération. Par exemple, vous pouvez envoyer des emails avec gmail quelques jours d'intervalle. Ils peuvent être sur le même objet et le corps, mais les deux e-mails doivent être envoyés.

Concernant la mise en cache du proxy:

Un proxy serveur HTTP qui transmet votre message au serveur ne serait jamais cache quelque chose, mais un GET ou un CHEF de demande.

Concernant la cache du serveur:

Un serveur par défaut ne serait pas de traiter automatiquement une requête POST via la vérification de sa cache. Mais bien sûr, un POSTE de demande peut être envoyée à votre application ou d'extension, et vous pouvez avoir votre propre cache que vous lisez à partir de quand les paramètres sont les mêmes.

De l'invalidation d'une ressource:

La vérification de la HTTP 1.1 RFC 2616 S. 13.10 montre que la méthode POST doit invalider les ressources pour la mise en cache.
- "Fondamentalement, la POSTE n'est pas une opération équipotente. Vous ne pouvez donc pas l'utiliser pour la mise en cache." C'est tout simplement faux, et il ne fait pas vraiment sens, voir redémarrer la réponse pour plus de détails. Malheureusement, je ne peux pas downvote encore, sinon je l'aurais.
- Eugene: j'ai changé "n'est pas" "ne peut pas".
- Merci Brian, qui sonne mieux. Mon problème avec ton "POST pas idemp. -> ne peut pas être mis en cache", mais a été - et je n'ai pas assez clair - même si une opération n'est pas la quantité qui ne signifie pas qu'il n'est pas mis en cache. Je suppose que la question est êtes-vous regarder du point de vue du serveur, qui offre des données et sait que sa sémantique, ou vous êtes à la recherche d'un côté de réception (que ce soit un proxy cache etc. ou un client). Si c'est le client proxy/pov, je suis totalement d'accord avec votre post. Si c'est le serveur de pov, si le serveur dit: "le client peut mettre en cache", que le client peut mettre en cache.
- Eugene: Si cela fait une différence si elle est appelée une fois ou 5 fois, comme si vous postez un message à la liste, alors vous voulez que l'appel à frapper le serveur 5 fois à droite? Et vous ne voulez pas mettre en cache afin de ne pas frapper le serveur? Parce qu'il y a des effets secondaires importants.
- [suite] j'ai cependant pas fait mon esprit que le serveur devrait envoyer de cache permettant d'en-tête expires SEULEMENT si l'opération est idempotent. Il semble plutôt logique, même si, je suppose. [viens de voir votre réponse]: d'Accord, donc je gues j'ai fait de mon esprit: le Serveur doit, seul le signal cacheability en cas d'idempotence - et qui pourrait être un POSTE en tant que bien, surtout compte tenu de la nécessité pour les X-HTTP-Method-Remplacer dans certains cas.
- L'OP a demandé si c'était possible, pas si cela doit être fait, et la spécification HTTP (comme mentionné dans d'autres réponses) indiquent qu'un serveur peut renvoyer en-têtes de cache pour indiquer que la réponse peut être mis en cache. Le reste des détails de votre réponse est la bonne.
InformationsquelleAutor Brian R. Bondy
7

Si vous ne vous cache un POST de réponse, il doit être à la direction de l'application web. C'est ce que l'on entend par "les Réponses à cette méthode ne sont pas cachable, à moins que la réponse appropriée Cache-Control ou l'Expiration de champs d'en-tête."

On peut supposer que l'application, qui sait si oui ou non les résultats d'un POSTE sont idempotents, décide de savoir si ou de ne pas attacher le nécessaire et approprié de contrôle de cache-têtes. Si les en-têtes qui suggèrent la mise en cache est permis sont présents, l'application est pour vous dire que le POST est, en réalité, un super-GET; que l'utilisation des POSTES de travail a été nécessaire en raison de la quantité de l'inutile et sans intérêt (pour l'utilisation de l'URI comme une clé de cache) les données nécessaires pour effectuer l'opération équipotente.

GET suivantes peuvent être servis à partir de la cache sous cette hypothèse.

Une application qui ne parvient pas à joindre le nécessaire et de corriger les en-têtes de différencier entre cachable " et non cachable POST des réponses est en faute pour n'importe quel invalide en cache les résultats.

Cela dit, chaque POST qui frappe le cache nécessite la validation à l'aide conditionnelle en-têtes. Ceci est nécessaire afin d'actualiser le contenu du cache pour éviter d'avoir les résultats d'un POSTE de ne pas être reflétés dans les réponses aux demandes jusqu'à ce que après la durée de vie de l'objet expire.

InformationsquelleAutor JohnS
4

Si c'est quelque chose qui n'est pas réellement modifier les données sur votre site, il devrait être d'une requête GET. Même si c'est un formulaire, vous pouvez toujours définir comme une requête get. Alors que, comme l'autre, vous pouvez mettre en cache les résultats d'un POST, ça n'aurait pas de sens sémantique, car un POST, par définition, est la modification des données.
- Le POSTE demande pourrait ne pas être en train de changer toutes les données qui est utilisée pour générer la page de réponse, auquel cas il pourrait faire sens pour mettre en cache la réponse.
- David Z: Assurément, si un POST est en train de changer les données de la réponse devrait donner une indication de succès ou d'échec. Pas nécessaire exactement, mais je ne peux pas penser à une situation où un POSTE de modifier des données et de la réponse statique.
- Si le paramètre de données est trop long, une requête GET ne fonctionne pas avec tous les serveurs, ce POST est nécessaire, en particulier si la source doit s'exécuter sur des serveurs que le code que l'auteur n'a pas la configuration.
InformationsquelleAutor Kibbee
3

Mark Nottingham a analysé lorsqu'il est possible de mettre en cache la réponse d'un POST. Notez que les demandes subséquentes qui veulent profiter de la mise en cache doit être GET ou HEAD demandes. Voir aussi httpbis

Postes de ne pas traiter dans les représentations de l'identifiés état, 99 fois sur 100.
Cependant, il existe un cas où c'est le cas, lorsque le serveur est hors de
sa façon de dire que ce POST de réponse est une représentation de son URI,
en définissant le Contenu de l'Emplacement de l'en-tête qui est la même que la demande
URI. Lorsque cela se produit, la réponse POST est juste comme une réponse
de la même URI; il peut être mis en cache et réutilisés, mais seulement pour l'avenir
Les requêtes GET.

https://www.mnot.net/blog/2012/09/24/caching_POST.

InformationsquelleAutor dschulten
1

Bien sûr, c'est possible. Si vous voulez prendre des requêtes POST envoyé à votre serveur, et de mettre en cache les données transmises à être ré-envoyé plus tard - pas de sueur.

La partie la plus délicate vient au sujet de "l'état". Comment décidez-vous les données que vous voulez envoyer à l'utilisateur devrait vraiment être le même? Que si les cookies ont changé, est - ce que modifier les données que vous voulez envoyer en arrière?

Que diriez-vous si l'utilisateur fait une requête POST vers votre page d'accueil, et depuis la dernière fois qu'il l'a fait, un autre utilisateur a envoyé un message (à l'aide d'un système à l'intérieur de votre site.) Vous devez identifier que comme un changement d'état, et envoyer la nouvelle version de votre page d'accueil, avec une notification de message à l'utilisateur la prochaine fois qu'il charge la page d'accueil. Même si le POSTE paramètres sont les mêmes.
- Possible, oui. Violation de la RFC 2616 (HTTP/1.1), également très probable. Breaking/pas de travail dans les navigateurs qui attendent HTTP/1.1, possible. Faites votre choix.
InformationsquelleAutor Shalom Craimer
-1

Avec firefox 27.0 & avec httpfox, le 19 Mai 2014, j'ai vu une ligne de ce:
00:03:58.777 0.488 657 (393) la POSTE (Cache) texte/html https://users.jackiszhp.info/S4UP

Clairement, la réponse de la méthode post est mis en cache, et c'est aussi en https.
Incroyable!

InformationsquelleAutor user1462586
-2

POST est utilisée dans la dynamique de l'Ajax. De retour d'une réponse en cache pour un POSTE défaites le canal de communication et les effets secondaires de la réception d'un message. C'est très Très Mauvais. C'est aussi une vraie douleur pour la piste vers le bas. Hautement recommandé contre.

Un exemple trivial serait un message, comme un effet secondaire, verse votre salaire de 10 000 $la semaine en cours. Vous NE voulez PAS d'obtenir le "OK, il est passé par!" retour a été mis en cache, la semaine dernière. D'autres, plus complexes du monde réel cas entraîner dans les mêmes hilarité.
- Pas vraiment une réponse POST utilisés pour toutes sortes de choses et parfois il y a des raisons valables de le voulez pour mettre en cache la réponse.
InformationsquelleAutor DragonLord

Vous devez vous connecter pour publier un commentaire.