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

151

Mit sehr einfacher Caching-Semantik: Wenn die Parameter identisch sind (und die URL natürlich identisch ist), ist dies ein Hit. Ist das möglich? Empfohlen?

Flybywire
quelle

Antworten:

93

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.

Diomidis Spinellis
quelle
1
Dieser Abschnitt gilt für einen Zwischencache (wie einen Caching-Proxyserver), nicht für den Ursprungsserver.
David Z
2
Der Ursprungsserver ist ein Broker zwischen HTTP und der Anwendung, die die POST-Anforderungen verarbeitet. Die Anwendung ist jenseits der HTTP-Grenze und kann tun, was sie will. Wenn das Zwischenspeichern für eine bestimmte POST-Anforderung sinnvoll ist, kann es kostenlos zwischengespeichert werden, so wie das Betriebssystem Festplattenanforderungen zwischenspeichern kann.
Diomidis Spinellis
2
Diomidis, Ihre Aussage, dass das Zwischenspeichern von POST-Anforderungen kein HTTP ist, ist falsch. Weitere Informationen finden Sie in der Antwort von reBoot. Es ist nicht sehr hilfreich, wenn oben die falsche Antwort angezeigt wird, aber so funktioniert Demokratie. Wenn Sie mit reBoot einverstanden sind, wäre es schön, wenn Sie Ihre Antwort korrigieren würden.
Eugene Beresovsky
2
Eugene, können wir uns darauf einigen, dass a) POST die zwischengespeicherte Entität ungültig machen sollte (gemäß Abschnitt 13.10), so dass z. B. ein nachfolgendes GET eine Fersh-Kopie abrufen muss und b) dass die Antwort des POST zwischengespeichert werden kann (gemäß Abschnitt 9.5), so dass z kann ein nachfolgender POST die gleiche Antwort erhalten?
Diomidis Spinellis
3
Dies wird durch HTTPbis geklärt; Eine Zusammenfassung finden Sie unter mnot.net/blog/2012/09/24/caching_POST .
Mark Nottingham
67

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.


quelle
2
+1 reBoot, danke, dass du das Header-Problem erklärt und auch die fehlerhaften Aussagen zu 13.10 korrigiert hast. Überraschenderweise erhielten diese falschen Antworten so viele positive Stimmen.
Eugene Beresovsky
3
Was ist der Unterschied zwischen "Ungültigmachen der Ressource für das Caching" und "Erstellen einer zwischengespeicherten Version des URI veraltet"? Wollen Sie damit sagen, dass der Server eine POST-Antwort zwischenspeichern darf, Clients jedoch möglicherweise nicht?
Gili
1
"Eine zwischengespeicherte Version des veralteten URI erstellen" gilt, wenn Sie denselben URI für 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 )
Stephen Connolly
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?
Siddhartha
33

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.

Brian R. Bondy
quelle
9
"Grundsätzlich ist POST keine idempotente Operation. Sie können sie also nicht zum Zwischenspeichern verwenden." Das ist einfach falsch und macht keinen Sinn. Weitere Informationen finden Sie in der Antwort von reBoot. Leider kann ich noch nicht abstimmen, sonst hätte ich.
Eugene Beresovsky
1
Eugene: Ich habe "ist nicht" in "darf nicht" geändert.
Brian R. Bondy
1
Danke Brian, das klingt besser. Mein Problem mit Ihrem "POST nicht idemp. -> kann nicht zwischengespeichert werden" war - und ich habe das nicht klar genug gemacht - obwohl eine Operation nicht idempotent ist, was nicht bedeutet, dass sie nicht zwischengespeichert werden kann. Ich denke, die Frage ist, ob Sie es aus der Sicht des Servers betrachten, der die Daten anbietet und deren Semantik kennt, oder ob Sie sie von der empfangenden Seite aus betrachten (sei es ein Caching-Proxy usw. oder ein Client). . Wenn es der Client / Proxy POV ist, stimme ich Ihrem Beitrag voll und ganz zu. Wenn es der Server-POV ist, wenn der Server sagt: "Client kann zwischenspeichern", dann kann Client zwischenspeichern.
Eugene Beresovsky
1
Eugene: Wenn es einen Unterschied macht, ob es einmal oder fünfmal aufgerufen wird, z. B. wenn Sie eine Nachricht an eine Liste senden, möchten Sie, dass dieser Anruf fünfmal auf den Server gelangt, oder? Und Sie möchten es nicht zwischenspeichern, damit es den Server nicht richtig trifft? Weil es wichtige Nebenwirkungen gibt.
Brian R. Bondy
[Fortsetzung] Ich habe mich jedoch nicht entschieden, ob der Server tatsächlich einen Cache-zulässigen Ablauf-Header senden soll, NUR wenn der Vorgang idempotent ist. Es macht aber irgendwie Sinn, denke ich. [habe gerade Ihre Antwort gesehen]: Einverstanden, also habe ich mich entschieden: Der Server sollte nur im Falle von Idempotenz die Cachefähigkeit signalisieren - und das könnte auch ein POST sein, insbesondere angesichts der Notwendigkeit einer X-HTTP-Methodenüberschreibung in manche Fälle.
Eugene Beresovsky
6

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.

JohnS
quelle
4

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.

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

dschulten
quelle
3

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.

Kibbee
quelle
Die POST-Anforderung ändert möglicherweise keine Daten, die zum Generieren der Antwortseite verwendet werden. In diesem Fall kann es sinnvoll sein, die Antwort zwischenzuspeichern.
David Z
David Z: Wenn ein POST Daten ändert, sollte die Antwort sicherlich einen Hinweis auf Erfolg / Misserfolg geben. Nicht genau erforderlich, aber ich kann mir keine Situation vorstellen, in der ein POST Daten ändern würde und die Antwort statisch wäre.
Morvael
6
Wenn die Parameterdaten zu lang sind, funktioniert eine GET-Anforderung nicht auf allen Servern. Daher ist POST erforderlich, insbesondere wenn die Quelle auf Servern ausgeführt werden soll, die der Code-Autor nicht konfiguriert.
Gogowitsch
@Gogowitsch sehr wahr, Sie werden auf einen 414-Fehlercode stoßen
Siddhartha
3

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.

RFC 2616

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:

  • "Ja, mit dem RFC können Sie POST-Anforderungen für nachfolgende GETs an dieselbe Ressource zwischenspeichern."
  • "Nein, mit dem RFC können Sie POST-Anforderungen für nachfolgende POSTs nicht zwischenspeichern, da POST nicht idempotent ist und auf den Server geschrieben werden muss."

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:

Demonstration des Browserverhaltens

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:

  • Wenn Sie auf "GET-Anforderung auslösen" klicken, wird jedes Mal die gleiche "Anzahl" angezeigt (HTTP-Caching funktioniert).
  • Wenn Sie auf "POST-Anforderung auslösen" klicken, wird jedes Mal eine andere Anzahl ausgelöst (das HTTP-Caching für POST funktioniert nicht).
  • Durch Klicken auf "GET-Anforderung auslösen", "POST-Anforderung auslösen" und "GET-Anforderung auslösen" wird angezeigt, dass die POST-Anforderung den Cache der GET-Anforderung ungültig macht.
  • Wenn Sie auf "POST-Anforderung auslösen" und dann auf "GET-Anforderung auslösen" klicken, wird angezeigt, dass Browser POST-Anforderungen für nachfolgende GET-Anforderungen nicht zwischenspeichern, obwohl dies vom RFC zugelassen wird.

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 .

Muss ich dem RFC folgen?

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 .

Soll ich POST-Anfragen zwischenspeichern?

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.

GraphQL

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.

timrs2998
quelle
-2

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!

user1462586
quelle
-3

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.

Drachen Lord
quelle
3
Keine wirkliche Antwort - POST wird für alle möglichen Dinge verwendet und manchmal gibt es triftige Gründe, die Antwort zwischenzuspeichern.
Alexei Levenkov