Antworten:
Der entsprechende RFC 2616 in Abschnitt 9.5 (POST) ermöglicht das Zwischenspeichern der Antwort auf eine POST-Nachricht, wenn Sie die entsprechenden Header verwenden.
Antworten auf diese Methode können nicht zwischengespeichert werden, es sei denn, die Antwort enthält entsprechende Cache-Control- oder Expires-Headerfelder. Die Antwort 303 (siehe Andere) kann jedoch verwendet werden, um den Benutzeragenten anzuweisen, eine zwischengespeicherte Ressource abzurufen.
Beachten Sie, dass derselbe RFC in Abschnitt 13 (Caching in HTTP) ausdrücklich angibt, dass ein Cache die entsprechende Entität nach einer POST- Anforderung ungültig machen muss .
Einige HTTP-Methoden MÜSSEN dazu führen, dass ein Cache eine Entität ungültig macht. Dies ist entweder die Entität, auf die sich der Anforderungs-URI bezieht, oder die Location- oder Content-Location-Header (falls vorhanden). Diese Methoden sind:
- PUT - DELETE - POST
Mir ist nicht klar, wie diese Spezifikationen ein sinnvolles Caching ermöglichen können.
Dies spiegelt sich auch in RFC 7231 (Abschnitt 4.3.3.) Wider und wird weiter präzisiert , wodurch RFC 2616 überholt wird.
Antworten auf POST-Anforderungen können nur zwischengespeichert werden, wenn sie
explizite Aktualitätsinformationen enthalten (siehe Abschnitt 4.2.1 von [RFC7234]).
Das POST-Caching ist jedoch nicht weit verbreitet. In Fällen, in denen ein Ursprungsserver möchte, dass der Client das Ergebnis eines POST auf eine Weise zwischenspeichern kann, die von einem späteren GET wiederverwendet werden kann, kann der Ursprungsserver eine Antwort von 200 (OK) senden, die das Ergebnis und einen Inhaltsspeicherort enthält Header-Feld, das denselben Wert wie der effektive Anforderungs-URI des POST hat (Abschnitt 3.1.4.2).
Demnach kann das Ergebnis eines zwischengespeicherten POST (wenn diese Fähigkeit vom Server angegeben wird) anschließend als Ergebnis einer GET-Anforderung für denselben URI verwendet werden.
Gemäß RFC 2616 Abschnitt 9.5:
"Antworten auf die POST-Methode können nicht zwischengespeichert werden, es sei denn, die Antwort enthält entsprechende Cache-Control- oder Expires-Header-Felder."
JA, Sie können die POST-Anforderungsantwort zwischenspeichern, jedoch nur, wenn sie mit den entsprechenden Headern eintrifft. In den meisten Fällen möchten Sie die Antwort nicht zwischenspeichern. In einigen Fällen - beispielsweise wenn Sie keine Daten auf dem Server speichern - ist dies jedoch völlig angemessen.
Beachten Sie jedoch, dass viele Browser, einschließlich des aktuellen Firefox 3.0.10, die POST-Antwort unabhängig von den Headern nicht zwischenspeichern. IE verhält sich in dieser Hinsicht schlauer.
Jetzt möchte ich hier einige Verwirrung in Bezug auf RFC 2616 S. 13.10 beseitigen. Die POST-Methode für einen URI macht die Ressource für das Caching nicht "ungültig", wie einige hier angegeben haben. Eine zuvor zwischengespeicherte Version dieses URI ist veraltet, selbst wenn die Header der Cache-Steuerung eine längere Aktualität anzeigen.
GETund POSTAnforderungen verwenden. Wenn Sie ein Cache zwischen dem Client und dem Server sind, wird GET /foodie Antwort angezeigt und zwischengespeichert . Weiter Sie sehen , POST /foodann werden Sie benötigt von der zwischengespeicherten Antwort ungültig zu machen , GET /fooauch wenn die POSTAntwort enthält keinen Cache - Control - Header , weil sie die gleiche URI sind , so dass die nächste GET /foowird auch revalidate haben , wenn die ursprünglichen Header die Cache noch angezeigt wäre live (wenn Sie die POST /fooAnfrage nicht gesehen hatten )
But in some cases - such as if you are not saving any data on the server - it's entirely appropriate.. Was bringt eine solche POST-API dann überhaupt?
Insgesamt:
Grundsätzlich ist POST keine idempotente Operation . Sie können es also nicht zum Zwischenspeichern verwenden. GET sollte eine idempotente Operation sein, daher wird es häufig zum Zwischenspeichern verwendet.
Siehe Abschnitt 9.1 des HTTP 1.1 RFC 2616 S. 9.1 .
Andere als die Semantik der GET-Methode:
Die POST-Methode selbst soll semantisch etwas an eine Ressource senden. POST kann nicht zwischengespeichert werden, da Sie die Ressource des Servers jedes Mal ändern, wenn Sie einmal oder zweimal oder dreimal etwas tun. Jede Anfrage ist wichtig und sollte an den Server gesendet werden.
Die PUT-Methode selbst ist semantisch dazu gedacht, eine Ressource zu platzieren oder zu erstellen. Es ist eine idempotente Operation, die jedoch nicht zum Zwischenspeichern verwendet wird, da in der Zwischenzeit möglicherweise ein LÖSCHEN aufgetreten ist.
Die DELETE-Methode selbst soll semantisch eine Ressource löschen. Es handelt sich um eine idempotente Operation, die jedoch nicht zum Zwischenspeichern verwendet wird, da in der Zwischenzeit möglicherweise ein PUT aufgetreten ist.
In Bezug auf clientseitiges Caching:
Ein Webbrowser leitet Ihre Anfrage immer weiter, auch wenn er eine Antwort von einem früheren POST-Vorgang hat. Beispielsweise können Sie E-Mails mit Google Mail im Abstand von einigen Tagen senden. Sie können denselben Betreff und denselben Text haben, aber beide E-Mails sollten gesendet werden.
In Bezug auf das Proxy-Caching:
Ein Proxy-HTTP-Server, der Ihre Nachricht an den Server weiterleitet, würde niemals etwas anderes als eine GET- oder eine HEAD-Anforderung zwischenspeichern.
In Bezug auf Server-Caching:
Ein Server würde eine POST-Anforderung standardmäßig nicht automatisch verarbeiten, indem er seinen Cache überprüft. Natürlich kann eine POST-Anfrage an Ihre Anwendung oder Ihr Add-In gesendet werden, und Sie können über einen eigenen Cache verfügen, aus dem Sie lesen, wenn die Parameter identisch sind.
Ungültigmachen einer Ressource:
Das Überprüfen von 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 zwischenspeichern, muss sie in Richtung der Webanwendung erfolgen. Dies ist gemeint mit "Antworten auf diese Methode können nicht zwischengespeichert werden, es sei denn, die Antwort enthält entsprechende Cache-Control- oder Expires-Header-Felder."
Man kann davon ausgehen, dass die Anwendung, die weiß, ob die Ergebnisse eines POST idempotent sind oder nicht, entscheidet, ob die erforderlichen und richtigen Cache-Steuerungsheader angehängt werden sollen oder nicht. Wenn Header vorhanden sind, die darauf hinweisen, dass das Zwischenspeichern zulässig ist, teilt Ihnen die Anwendung mit, dass der POST in Wirklichkeit ein Super-GET ist. dass die Verwendung von POST nur aufgrund der Menge an unnötigen und irrelevanten Daten (für die Verwendung des URI als Cache-Schlüssel) erforderlich war, die zur Durchführung der idempotenten Operation erforderlich waren.
Folgende GETs können unter dieser Annahme aus dem Cache bereitgestellt werden.
Eine Anwendung, die nicht die erforderlichen und korrekten Header anfügt, um zwischen zwischenspeicherbaren und nicht zwischenspeicherbaren POST-Antworten zu unterscheiden, ist für ungültige Zwischenspeicherungsergebnisse verantwortlich.
Das heißt, jeder POST, der in den Cache gelangt, muss mithilfe von bedingten Headern überprüft werden. Dies ist erforderlich, um den Cache-Inhalt zu aktualisieren und zu vermeiden, dass die Ergebnisse eines POST erst nach Ablauf der Lebensdauer des Objekts in den Antworten auf Anforderungen berücksichtigt werden.
Mark Nottingham hat analysiert, wann es möglich ist, die Antwort eines POST zwischenzuspeichern. Beachten Sie, dass die nachfolgenden Anforderungen, die das Caching nutzen möchten, GET- oder HEAD-Anforderungen sein müssen. Siehe auch http-Semantik
POSTs befassen sich nicht mit Darstellungen des identifizierten Zustands, 99-mal von 100. Es gibt jedoch einen Fall, in dem dies der Fall ist. Wenn der Server sich Mühe gibt zu sagen, dass diese POST-Antwort eine Darstellung seines URI ist, indem er einen Content-Location-Header festlegt, der mit dem Anforderungs-URI identisch ist. In diesem Fall entspricht die POST-Antwort einer GET-Antwort auf denselben URI. Es kann zwischengespeichert und wiederverwendet werden - jedoch nur für zukünftige GET-Anforderungen.
Wenn es etwas ist, das die Daten auf Ihrer Site nicht wirklich ändert, sollte es eine GET-Anfrage sein. Auch wenn es sich um ein Formular handelt, können Sie es dennoch als Abrufanforderung festlegen. Wie andere betonen, könnten Sie die Ergebnisse eines POST zwischenspeichern, dies wäre jedoch semantisch nicht sinnvoll, da ein POST per Definition Daten ändert.
Wenn Sie sich fragen, ob Sie eine Post-Anfrage zwischenspeichern und versuchen können, eine Antwort auf diese Frage zu finden, werden Sie wahrscheinlich keinen Erfolg haben. Bei der Suche nach "Cache-Post-Anfrage" ist das erste Ergebnis diese StackOverflow-Frage.
Die Antworten sind eine verwirrende Mischung aus der Funktionsweise von Caching, der Funktionsweise von Caching gemäß RFC, der Funktionsweise von Caching gemäß RFC und der Funktionsweise von Caching in der Praxis. Beginnen wir mit dem RFC, gehen wir eine Demonstration der tatsächlichen Funktionsweise des Browsers durch und sprechen dann über CDNs, GraphQL und andere Problembereiche.
Gemäß RFC müssen POST-Anforderungen den Cache ungültig machen:
13.10 Invalidation After Updates or Deletions
..
Some HTTP methods MUST cause a cache to invalidate an entity. This is
either the entity referred to by the Request-URI, or by the Location
or Content-Location headers (if present). These methods are:
- PUT
- DELETE
- POST
Diese Sprache legt nahe, dass POST-Anforderungen nicht zwischengespeichert werden können, dies ist jedoch (in diesem Fall) nicht der Fall. Der Cache wird nur für zuvor gespeicherte Daten ungültig. Der RFC (scheint) explizit zu verdeutlichen, dass Sie POSTAnforderungen zwischenspeichern können:
9.5 POST
..
Responses to this method are not cacheable, unless the response
includes appropriate Cache-Control or Expires header fields. However,
the 303 (See Other) response can be used to direct the user agent to
retrieve a cacheable resource.
Trotz dieser Sprache Cache-Controldarf das Festlegen von keine nachfolgenden POSTAnforderungen an dieselbe Ressource zwischenspeichern. POSTAnfragen müssen an den Server gesendet werden:
13.11 Write-Through Mandatory
..
All methods that might be expected to cause modifications to the
origin server's resources MUST be written through to the origin
server. This currently includes all methods except for GET and HEAD.
A cache MUST NOT reply to such a request from a client before having
transmitted the request to the inbound server, and having received a
corresponding response from the inbound server. This does not prevent
a proxy cache from sending a 100 (Continue) response before the
inbound server has sent its final reply.
Wie macht das Sinn? Nun, Sie speichern die POSTAnforderung nicht zwischen, sondern zwischen den Ressourcen.
Der POST-Antworttext kann nur für nachfolgende GET-Anforderungen an dieselbe Ressource zwischengespeichert werden. Setzen Sie den Header Locationoder Content-Locationin der POST-Antwort, um mitzuteilen, welche Ressource der Body darstellt. Die einzige technisch gültige Möglichkeit, eine POST-Anforderung zwischenzuspeichern, besteht darin, nachfolgende GETs an dieselbe Ressource zu senden.
Die richtige Antwort lautet beides:
Obwohl der RFC das Zwischenspeichern von Anforderungen an dieselbe Ressource ermöglicht, implementieren Browser und CDNs dieses Verhalten in der Praxis nicht und erlauben Ihnen nicht, POST-Anforderungen zwischenzuspeichern.
Quellen:
Anhand des folgenden Beispiels einer JavaScript-Anwendung (index.js):
const express = require('express')
const app = express()
let count = 0
app
.get('/asdf', (req, res) => {
count++
const msg = `count is ${count}`
console.log(msg)
res
.set('Access-Control-Allow-Origin', '*')
.set('Cache-Control', 'public, max-age=30')
.send(msg)
})
.post('/asdf', (req, res) => {
count++
const msg = `count is ${count}`
console.log(msg)
res
.set('Access-Control-Allow-Origin', '*')
.set('Cache-Control', 'public, max-age=30')
.set('Content-Location', 'http://localhost:3000/asdf')
.set('Location', 'http://localhost:3000/asdf')
.status(201)
.send(msg)
})
.set('etag', false)
.disable('x-powered-by')
.listen(3000, () => {
console.log('Example app listening on port 3000!')
})Und angesichts der folgenden Beispielwebseite (index.html):
<!DOCTYPE html>
<html>
<head>
<script>
async function getRequest() {
const response = await fetch('http://localhost:3000/asdf')
const text = await response.text()
alert(text)
}
async function postRequest(message) {
const response = await fetch(
'http://localhost:3000/asdf',
{
method: 'post',
body: { message },
}
)
const text = await response.text()
alert(text)
}
</script>
</head>
<body>
<button onclick="getRequest()">Trigger GET request</button>
<br />
<button onclick="postRequest('trigger1')">Trigger POST request (body 1)</button>
<br />
<button onclick="postRequest('trigger2')">Trigger POST request (body 2)</button>
</body>
</html>Installieren Sie NodeJS, Express und starten Sie die JavaScript-Anwendung. Öffnen Sie die Webseite in Ihrem Browser. Probieren Sie verschiedene Szenarien aus, um das Verhalten des Browsers zu testen:
Dies zeigt, dass es keine Möglichkeit gibt, einen Browser-Cache zu einer HTTP-POST-Anforderung zu machen , obwohl Sie die Header Cache-Controlund die Content-LocationAntwortheader festlegen können .
Das Browserverhalten ist nicht konfigurierbar, aber wenn Sie kein Browser sind, sind Sie nicht unbedingt an die Regeln des RFC gebunden.
Wenn Sie Anwendungscode schreiben, hindert Sie nichts daran, POST-Anforderungen (Pseudocode) explizit zwischenzuspeichern:
if (cache.get('hello')) {
return cache.get('hello')
} else {
response = post(url = 'http://somewebsite/hello', request_body = 'world')
cache.put('hello', response.body)
return response.body
}CDNs, Proxys und Gateways müssen ebenfalls nicht unbedingt dem RFC folgen. Wenn Sie beispielsweise Fastly als CDN verwenden, können Sie mit Fastly eine benutzerdefinierte VCL- Logik schreiben, um POST-Anforderungen zwischenzuspeichern .
Ob Ihre POST-Anfrage zwischengespeichert werden soll oder nicht, hängt vom Kontext ab.
Beispielsweise können Sie Elasticsearch oder GraphQL mithilfe von POST abfragen, wobei Ihre zugrunde liegende Abfrage idempotent ist. In diesen Fällen kann es je nach Anwendungsfall sinnvoll sein, die Antwort zwischenzuspeichern oder nicht.
In einer RESTful-API erstellen POST-Anforderungen normalerweise eine Ressource und sollten nicht zwischengespeichert werden. Dies ist auch das Verständnis des RFC von POST, dass es sich nicht um eine idempotente Operation handelt.
Wenn Sie GraphQL verwenden und HTTP-Caching zwischen CDNs und Browsern benötigen, prüfen Sie, ob das Senden von Abfragen mit der GET-Methode Ihren Anforderungen anstelle von POST entspricht . Als Einschränkung können unterschiedliche Browser und CDNs unterschiedliche URI-Längenbeschränkungen haben, aber die sichere Auflistung von Vorgängen (Abfrage-Whitelist) als bewährte Methode für GraphQL-Apps für die externe Produktion kann URIs verkürzen.
Mit Firefox 27.0 und mit httpfox sah ich am 19. Mai 2014 eine Zeile davon: 00: 03: 58.777 0.488 657 (393) POST (Cache) text / html https://users.jackiszhp.info/S4UP
Die Antwort einer Post-Methode wird eindeutig zwischengespeichert, und sie befindet sich auch in https. Unglaublich!
POST wird in Stateful Ajax verwendet. Das Zurückgeben einer zwischengespeicherten Antwort für einen POST beseitigt den Kommunikationskanal und die Nebenwirkungen des Empfangs einer Nachricht. Das ist sehr sehr schlecht. Es ist auch ein echtes Problem, es aufzuspüren. Sehr zu empfehlen gegen.
Ein triviales Beispiel wäre eine Nachricht, die als Nebeneffekt Ihr Gehalt in der aktuellen Woche auf 10.000 US-Dollar zahlt. Sie wollen nicht das "OK, es ging durch!" Seite zurück, die letzte Woche zwischengespeichert wurde. Andere, komplexere Fälle aus der realen Welt führen zu einer ähnlichen Heiterkeit.