Ist es möglich, POST-Methoden in HTTP-Cache?

StackOverflow https://stackoverflow.com/questions/626057

  •  05-07-2019
  •  | 
  •  

Frage

Mit sehr einfachen Caching-Semantik: Wenn die Parameter gleich sind (und die URL ist die gleiche, natürlich), dann ist es ein Hit. Ist das möglich? Empfohlen?

War es hilfreich?

Lösung

Die entsprechenden RFC 2616 in Abschnitt 9.5 (POST) ermöglicht das Zwischenspeichern von < strong> Antwort auf eine POST-Meldung, wenn Sie die entsprechenden Header verwenden.

  

Die Antworten auf diese Verfahren sind nicht zwischenspeicherbar, es sei denn, die Antwort   enthält geeignete Cache-Control-Header-Felder oder Ablaufdatum. Jedoch,   die 303 (siehe andere) Antwort kann den User-Agent zu lenken verwendet werden, um   Abrufen cacheunterstützbare Ressource.

Beachten Sie, dass die gleiche RFC heißt es ausdrücklich in Abschnitt 13 (Caching in HTTP), dass ein Cache die entsprechende Einheit nach einer POST Anfrage ungültig machen muß .

  

Einige HTTP-Methoden muss ein verursachen   Cache eine Einheit zu entkräften. Das ist   entweder die Einrichtung im Sinne von der   Request-URI oder durch den Ort oder   Content-Location-Header (falls vorhanden).   Diese Methoden sind: 

  - PUT
  - DELETE
  - POST

Es ist mir nicht klar, wie diese Daten sinnvoll Caching erlauben können.

Andere Tipps

Nach RFC 2616 Abschnitt 9.5:

  

"Responses to Methode POST nicht   zwischenspeicherbar, es sei denn die Reaktion   enthält geeigneter Cache-Control oder   Expires Header-Felder. "

Also, ja, können Sie POST-Anfrage-Antwort-Cache aber nur, wenn es kommt mit dem entsprechenden Header. In den meisten Fällen wollen Sie nicht die Antwort zwischenzuspeichern. Aber in einigen Fällen - wie zum Beispiel, wenn Sie nicht alle Daten auf dem Server speichern kann - es ist durchaus angemessen.

Beachten Sie jedoch viele Browser, einschließlich der aktuellen Firefox 3.0.10, nicht unabhängig von den Header POST Antwort zwischenzuspeichern. IE verhält sich intelligent in dieser Hinsicht.

Nun, ich möchte in Bezug auf einige Verwirrung hier aufzuräumen RFC 2616 S. 13.10. POST-Methode auf einer URI „ungültig machen die Ressource für das Caching“ nicht wie einige hier angegeben haben. Es macht eine zuvor gespeicherte Version des URI abgestanden, auch wenn sein Cache-Control-Header angegeben Frische von längerer Dauer.

Gesamt:

Im Grunde POST ist nicht idempotent Betrieb . So können Sie es nicht für das Caching verwenden. GET sollte ein idempotent Betrieb sein, so ist es häufig für das Caching verwendet.

Bitte beachten Sie Abschnitt 9.1 der HTTP 1.1 RFC 2616 S. 9.1 .

Andere als GET-Methode der Semantik:

Die POST-Methode selbst ist semantisch schreiben etwas auf eine Ressource gemeint. POST kann nicht, weil zwischengespeichert werden, wenn Sie etwas einmal tun vs zweimal vs dreimal, dann werden Sie die Ressource jedes Mal des Servers zu ändern. Jede Anfrage Angelegenheiten und sollen an den Server geliefert werden.

Die PUT-Methode selbst ist semantisch eine Ressource setzen oder erstellen soll. Es ist ein idempotent Betrieb, aber es wird nicht für das Caching verwendet werden, da ein DELETE in der Zwischenzeit stattgefunden haben könnte.

Die DELETE-Methode selbst ist semantisch eine Ressource löschen soll. Es ist ein idempotent Betrieb, aber es wird nicht für das Caching verwendet werden, da ein PUT in der Zwischenzeit stattgefunden haben könnte.

In Bezug auf Client-seitiges Caching:

Ein Web-Browser wird immer uns auf Ihre Anfrage, auch wenn es eine Antwort von einer früheren POST-Operation hat. Zum Beispiel können Sie neben E-Mails mit Google Mail ein paar Tagen senden. Sie können das gleiche Thema und Körper sein, aber beide E-Mails gesendet werden sollen.

In Bezug auf Proxy-Caching:

Ein Proxy-HTTP-Server, der Ihre Nachricht an den Server weiterleitet würde nie etwas anderes als ein GET-Cache oder eine HEAD-Anfrage.

In Bezug auf Server-Caching:

Ein Server standardmäßig nicht automatisch eine POST-Anforderung über die Überprüfung seiner Cache behandeln. Aber natürlich eine POST-Anfrage an Ihre Anwendung gesendet werden, oder Add-in und Sie können Ihre eigenen Cache haben, die Sie lesen aus, wenn die Parameter gleich sind.

Invalidierung eine Ressource:

Überprüfen der HTTP 1.1 RFC 2616 S. 13.10 zeigt, dass die POST-Methode, die Ressource für das Caching ungültig machen sollte.

Wenn Sie eine POST-Antwort tun zwischenzuspeichern, muss es in Richtung der Web-Anwendung sein. Dies ist, was ist gemeint mit „Antworten auf diese Methode nicht cachable sind, es sei denn, die Reaktion geeigneten Cache-Control enthält oder Expires Header-Felder.“

Man kann sicher davon ausgehen, dass die Anwendung, die, ob die Ergebnisse einer POST weiß sind idempotent, entscheidet, ob oder nicht die notwendigen und richtigen Cache Control-Header zu befestigen. Wenn Header, die Caching vorschlagen darf vorhanden sind, wird die Anwendung, die Sie sagen, dass die POST ist in Wirklichkeit ein Super-GET; dass die Verwendung von POST nur aufgrund der Menge an unnötig und irrelevant (die Verwendung des URI als Cache key) Daten erforderlich war, notwendig, die idempotent Operation auszuführen.

Nach GET der kann aus dem Cache unter dieser Annahme bedient werden.

Eine Anwendung, die die notwendigen und richtigen Header zu unterscheiden zwischen cachable und nicht-cachable POST Antworten anhängen nicht ein Verschulden trifft nach ungültigen Caching Ergebnisse.

sagte, dass jeder POST, der den Cache-Treffer erfordert Validierung mithilfe der bedingten Header. Dies ist erforderlich, um den Cache-Inhalt zu aktualisieren, um zu vermeiden, die Ergebnisse mit einer POST nicht in den Antworten auf Anfragen bis reflektiert werden, nachdem die Lebensdauer des Objekts abgelaufen ist.

Wenn es etwas, das tatsächlich keine Daten auf Ihrer Website ändern, sollte es eine GET-Anforderung sein. Auch wenn es eine Form ist, können Sie es immer noch als Erhaltungs-Anforderung gesetzt. Während wie andere weisen darauf hin, können Sie die Ergebnisse einer POST-Cache könnte, wäre es nicht semantisch sinnvoll, da eine POST per Definition Daten zu ändern.

Mark Nottingham hat untersucht, wenn es möglich ist, die Antwort eines POST zu zwischenzuspeichern. sein muss, GET oder HEAD-Anforderungen zu beachten, dass die folgenden Anforderungen, die die Vorteile von Caching nehmen wollen. Siehe auch httpbis

  

POSTs handeln nicht in Darstellungen Zustand befindet, in 99 von 100.   Allerdings gibt es einen Fall, in dem es tut; wenn der Server geht aus   seine Art und Weise zu sagen, dass diese POST-Antwort eine Darstellung seiner URI ist,   durch ein Content-Location-Header Einstellung, die die gleiche wie die Anforderung ist   URI. Wenn das passiert, ist die POST-Antwort wie eine GET-Antwort   auf den gleichen URI; es kann im Cache gespeichert und wiederverwendet werden - aber nur für Zukunft   GET-Anfragen.

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

Natürlich ist es möglich. Wenn Sie auf Ihren Server gesendet POST-Anfragen zu fangen, und zwischenspeichern die Daten zurückgeschickt erneut gesendet später werden. - keinen Schweiß

Der schwierige Teil kommt in Bezug auf „Staat“. Wie entscheiden Sie, welche Daten Sie wirklich wollen, sollten die gleichen sein, um dem Benutzer zurückschicken? Was passiert, wenn seine Cookies geändert haben - nicht, dass die Daten ändern, die Sie zurückschicken wollen

?

Wie wäre es, wenn der Benutzer eine POST-Anforderung zu Ihrer Homepage gemacht, und seit dem letzten Mal, wenn er das getan hat, ein anderer Benutzer eine Nachricht geschickt ihm (einige System innerhalb Ihrer Website.) Sie müssten, dass identifizieren als Change- of-Zustand, und die neue Version Ihrer Homepage, mit einer Benachrichtigung über die Nachricht an den Benutzer sendet das nächste Mal, wenn er die Homepage lädt. Auch wenn die POST-Parameter sind die gleichen.

Mit Firefox 27.0 und mit HttpFox, am 19. Mai 2014 sah ich eine Zeile folgt aus: 00: 03: 58,777 0,488 657 (393) POST (Cache) text / html https://users.jackiszhp.info/ S4UP

Natürlich ist die Antwort einer post-Methode zwischengespeichert, und es ist auch in https. Unglaublich!

POST wird in Stateful Ajax verwendet. eine zwischengespeicherte Antwort für eine Stelle zurückkehr besiegt den Kommunikationskanal und die Nebenwirkungen der eine Nachricht empfängt. Das ist sehr, sehr schlecht. Es ist auch ein echten Schmerzen aufzuspüren. Sehr zu empfehlen dagegen.

Ein triviales Beispiel wäre eine Nachricht, die als Nebenwirkung, Ihr Gehalt 10.000 die aktuelle Woche $ bezahlt. Sie wollen nicht das bekommen „OK, es ging durch!“ Seite zurück, die letzte Woche zwischengespeichert wurde. Andere, komplexere realen Fällen zu ähnlichen hilarity.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top