Wenn eine Antwort von einem Webserver mit einem Authorization -Header gemäß der OAuth-Spezifikation vorliegt, kann das HTTP-Caching nicht sinnvoll sein?
In diesem Fall würde bei gegebenem HTTP-Caching die zweite Anfrage die zwischengespeicherte Antwort für den ersten Benutzer zurückgeben. Dies ist kein Problem für Inhalte, die für alle Benutzer generisch sind. Dies ist jedoch falsch, wenn ein gemeinsam genutzter Cache Antworten für andere Benutzer bereitstellt.
Wenn wir also einen Header Vary verwenden und um Authorization variieren würden, würde unser Cache eine zwischengespeicherte Kopie pro Token speichern, die den Zweck des HTTP-Caching sicher vereitelt. Der lokale Cache des Browsers (privat) würde funktionieren, aber dies würde immer noch eine Ursprungsanforderung von jedem Benutzer mindestens einmal pro Sitzung bedeuten.
Bearbeiten
Der fragliche Dienst erfordert die Autorisierung für alle Anfragen. Auf der Grundlage dessen, was ich gelesen habe, sollten Antworten aus einem freigegebenen Cache, die Authorization-Header enthalten, nicht ausgeführt werden, sofern must-revalidate, public und s-maxage vorhanden sind .
Meine Frage lautet daher, dass bei einer API, die sowohl über generische (Antworten für alle Benutzer) als auch über benutzerspezifische Antworten verfügt, Caching sogar möglich ist? Mit s-maxage und öffentlichen Headern, aber einem Autorisierungsheader würde bedeuten, dass der Cache die Antwort von UserA auf UserB, UserC und so weiter auflösen würde, wenn ich den RFC korrekt befolge.
Siehe Ссылка :
"Ein Cache darf KEINE Antwort auf eine Anfrage speichern, außer: Die Anforderungsmethode wird vom Cache verstanden und als zwischenspeicherbar definiert ... das Autorisierungsheaderfeld (siehe Abschnitt 4.2 von [RFC7235]) erscheint nicht in der Anfrage, ... "
Tags und Links http caching http-caching