Avec la sémantique de mise en cache très simple : si les paramètres sont les mêmes (et l’url est le même, bien sûr), alors c’est un succès. Est-ce possible ? Recommandé ?
Réponses
Trop de publicités?
Le correspondant de 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.
Notez 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 de 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 les suivantes:
- PUT - DELETE - POST
Il n'est pas clair pour moi comment ces caractéristiques peuvent permettre de sens de la mise en cache.
Brian R. Bondy
Points
141769
Général:
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 d'OBTENIR 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é pour le 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 le proxy de mise en cache:
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 le serveur de mise en cache:
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.
L'invalidation d'une ressource:
Vérifier le HTTP 1.1 RFC 2616 S. 13.10 montre que la méthode POST doit invalider les ressources pour la mise en cache.
Kibbee
Points
36474
Si c’est quelque chose qui ne change en fait les données sur votre site, il faut une demande GET. Même si c’est une forme, vous pouvez encore le définir comme une demande get. Alors que, comme d’autres font remarquer, vous pourriez mettre en cache les résultats d’un poste, il ne ferait aucun sens sémantique car un POST par définition évolue données.
scraimer
Points
7000
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.
