ResponseCache-Richtlinie

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation.
Weitere Informationen

Speichert Daten aus einer Backend-Ressource im Cache, wodurch die Anzahl der Anfragen an die Ressource reduziert wird. Wenn Anwendungen Anfragen an denselben URI senden, können Sie mit dieser Richtlinie im Cache gespeicherte Antworten zurückgeben, anstatt diese Anfragen an den Back-End-Server weiterzuleiten. Die ResponseCache-Richtlinie kann die Leistung Ihrer API durch reduzierte Latenz und reduzierten Netzwerktraffic verbessern.

Wahrscheinlich finden Sie ResponseCache am nützlichsten, wenn die von Ihrer API verwendeten Backend-Daten nur in bestimmten Abständen aktualisiert werden. Angenommen, Sie haben eine API, die Wetterberichtsdaten nur alle 10 Minuten aktualisiert. Wenn Sie ResponseCache verwenden, um im Cache gespeicherte Antworten zwischen Aktualisierungen zurückzugeben, können Sie die Anzahl der Anfragen verringern, die das Back-End erreichen. Hierdurch wird auch die Anzahl der Netzwerk-Hops reduziert.

Für kurzfristiges Speichern im Cache für allgemeine Zwecke kann es sinnvoll sein, die PopulateCache-Richtlinie zu verwenden. Diese Richtlinie wird in Verbindung mit der LookupCache-Richtlinie (zum Lesen von Cache-Einträgen) und der InvalidateCache-Richtlinie (zum Entwerten von Einträgen) verwendet.

In diesem Video erhalten Sie eine Einführung in die ResponseCache-Richtlinie.

Beispiele

10-Minuten-Cache

In diesem Beispiel wird gezeigt, wie Antworten im Cache für zehn Minuten gespeichert werden.

Angenommen, Sie haben eine API unter der folgenden URL:

http://{org_name}-test.apigee.net/weather/forecastrss?w=23424778

Sie verwenden den Abfrageparameter w als Cache-Schlüssel. Apigee Edge prüft die des Abfrageparameters w beim Empfang einer Anfrage. Wenn der Cache eine gültige Antwort (also nicht abgelaufen) enthält, wird die im Cache gespeicherte Antwortnachricht an den anfordernden Client zurückgegeben.

Angenommen, Sie haben eine ResponseCache-Richtlinie mit folgender Konfiguration:

<ResponseCache name="ResponseCache">
    <CacheKey>
        <KeyFragment ref="request.queryparam.w" />
    </CacheKey>
    <ExpirySettings>
        <TimeoutInSeconds>600</TimeoutInSeconds>
    </ExpirySettings>
</ResponseCache>

Wenn der API-Proxy zum ersten Mal eine Anfragenachricht für die folgende URL empfängt, wird die Antwort im Cache gespeichert. Bei der zweiten Anfrage erfolgt innerhalb von zehn Minuten eine Cache-Suche. Die im Cache gespeicherte Antwort wird ohne Anforderung an den Back-End-Dienst an die Anwendung zurückgegeben.

http://{org_name}-test.apigee.net/weather/forecastrss?w=23424778

Cache-Suche überspringen

Das folgende Beispiel zeigt, wie Sie die Cache-Suche überspringen und den Cache aktualisieren. Weitere Informationen zur Verwendung von SkipCacheLookup finden Sie in diesem Video.

Die optionale Bedingung „SkipCacheLookup“ (falls konfiguriert) wird im Anfragepfad ausgewertet. Wenn die Bedingung als „true“ ausgewertet wird, wird der Cache-Suchvorgang übersprungen und der Cache wird aktualisiert.

Eine häufige Verwendung der bedingten Cache-Aktualisierung ist eine Bedingung, die einen bestimmten HTTP-Header definiert, der bewirkt, dass die Bedingung als „true“ ausgewertet wird. Eine skriptbasierte Clientanwendung kann so konfiguriert werden, dass sie regelmäßig eine Anfrage mit dem entsprechenden HTTP-Header sendet, was explizit zu einer Aktualisierung des Antwortcache führt.

Stellen Sie sich beispielsweise den Aufruf einer API unter der folgenden URL vor:

'http://{org_name}-test.apigee.net/weather/forecastrss?w=23424778' -H "bypass-cache:true"

Betrachten Sie nun die folgende ResponseCache-Richtlinie, die für diesen Proxy konfiguriert ist. Beachten Sie, dass die Bypass-Cache-Bedingung auf „true” gesetzt ist.

<ResponseCache name="ResponseCache">
    <CacheKey>
        <KeyFragment ref="request.queryparam.w" />
    </CacheKey>
    <!-- Explicitly refresh the cached response -->
    <SkipCacheLookup>request.header.bypass-cache = "true"</SkipCacheLookup>
    <ExpirySettings>
        <TimeoutInSeconds>600</TimeoutInSeconds>
    </ExpirySettings>
</ResponseCache>

Weitere Informationen zu Bedingungen finden Sie unter Ablaufvariablen und -bedingungen.

Elementverweis

Die Elementreferenz beschreibt die Elemente und Attribute der Richtlinie:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ResponseCache async="false" continueOnError="false" enabled="true" name="Response-Cache-1">
    <DisplayName>Response Cache 1</DisplayName>
    <Properties/>
    <CacheKey>
        <Prefix/>
        <KeyFragment ref="request.uri" />
    </CacheKey>
    <Scope>Exclusive</Scope>
    <ExpirySettings>
        <ExpiryDate/>
        <TimeOfDay/>
        <TimeoutInSeconds ref="flow.variable.here">300</TimeoutInSeconds>
    </ExpirySettings>
    <CacheResource>cache_to_use</CacheResource>
    <CacheLookupTimeoutInSeconds/>
    <ExcludeErrorResponse/>
    <SkipCacheLookup/>
    <SkipCachePopulation/>
    <UseAcceptHeader/>
    <UseResponseCacheHeaders/>
</ResponseCache>

<ResponseCache>-Attribute

<ResponseCache async="false" continueOnError="false" enabled="true" name="Response-Cache-1">

In der folgenden Tabelle werden Attribute beschrieben, die für alle übergeordneten Richtlinienelemente gelten:

Attribut Beschreibung Standard Präsenz
name

Der interne Name der Richtlinie. Der Wert des Attributs name kann Buchstaben, Ziffern, Leerzeichen, Bindestriche, Unterstriche und Punkte enthalten. Dieser Wert darf 255 Zeichen nicht überschreiten.

Optional können Sie das Element <DisplayName> verwenden, um die Richtlinie im Proxy-Editor der Verwaltungs-UI mit einem anderen Namen in einer natürlichen Sprache zu versehen.

Erforderlich
continueOnError

Legen Sie false fest, um einen Fehler zurückzugeben, wenn eine Richtlinie fehlschlägt. Dies ist für die meisten Richtlinien das erwartete Verhalten.

Legen Sie true fest, damit die Ablaufausführung auch nach dem Fehlschlagen einer Richtlinie fortgesetzt wird.

false Optional
enabled

Setzen Sie den Wert auf true, um die Richtlinie zu erzwingen.

Legen Sie false fest, um die Richtlinie zu deaktivieren. Die Richtlinie wird nicht erzwungen, selbst wenn sie mit einem Ablauf verknüpft ist.

true Optional
async

Dieses Attribut wurde verworfen.

false Veraltet

<DisplayName>-Element

Wird zusätzlich zum Attribut name verwendet, um die Richtlinie im Proxy-Editor der Verwaltungs-UI mit einem anderen Namen in einer natürlichen Sprache zu versehen.

<DisplayName>Policy Display Name</DisplayName>
Standardeinstellung

Wenn Sie dieses Element weglassen, wird der Wert des Namensattributs name der Richtlinie verwendet.

Präsenz Optional
Typ String

<CacheKey>-Element

Konfiguriert einen eindeutigen Zeiger auf ein im Cache gespeichertes Datenelement.

Cache-Schlüssel sind auf eine Größe von 2 KB begrenzt.

<CacheKey>
    <Prefix>string</Prefix>
    <KeyFragment ref="variable_name" />
    <KeyFragment>literal_string</KeyFragment>
</CacheKey>

Standardeinstellung:

Präsenz:

Erforderlich

Typ:

<CacheKey> erstellt den Namen jedes Datenelements, das im Cache gespeichert ist. Der Schlüssel wird häufig mithilfe eines Werts aus Entitäts-Headern oder Abfrageparametern festgelegt. In diesen Fällen hätte das Attribut „ref” des Elements eine Variable enthalten, die den Schlüsselwert enthält.

Zur Laufzeit werden <KeyFragment>-Werte entweder dem <Scope>-Elementwert oder dem <Prefix>-Wert vorangestellt. Das folgende Beispiel führt zu einem Cacheschlüssel von UserToken__apiAccessToken__<value_of_client_id>:

<CacheKey>
    <Prefix>UserToken</Prefix>
    <KeyFragment>apiAccessToken</KeyFragment>
    <KeyFragment ref="request.queryparam.client_id" />
</CacheKey>

Sie verwenden das <CacheKey>-Element zusammen mit <Prefix> und <Scope>. Weitere Informationen finden Sie unter Mit Cache-Schlüsseln arbeiten.

<CacheLookupTimeoutInSeconds>-Element

Gibt die Anzahl der Sekunden an, nach denen eine fehlgeschlagene Cache-Suche als Cache-Fehler betrachtet wird. In diesem Fall wird der Ablauf entlang des Cache-Fehler-Pfads fortgesetzt.

<CacheLookupTimeoutInSeconds>30</CacheLookupTimeoutInSeconds>

Standard:

30

Präsenz:

Optional

Typ:

Integer

<CacheResource>-Element

Gibt den Cache an, in dem Nachrichten gespeichert werden sollen. Lassen Sie dieses Element aus, um den enthaltenen freigegebenen Cache zu verwenden. Sie sollten eine CacheResource namentlich angeben, wenn Sie im Cache enthaltene Einträge administratives Löschen. Weitere Informationen dazu finden Sie unter Caches.

<CacheResource>cache_to_use</CacheResource>

Standardeinstellung:

Präsenz:

Optional

Typ:

String

Weitere Informationen zum Konfigurieren von Caches finden Sie unter Umgebungs-Cache erstellen und bearbeiten.

<CacheKey>/<KeyFragment>-Element

Gibt einen Wert an, der im Cache-Schlüssel enthalten sein muss, um einen Namespace für den Abgleich von Anfragen mit im Cache gespeicherten Antworten zu erstellen.

<KeyFragment ref="variable_name"/>
<KeyFragment>literal_string</KeyFragment>

Standard:

Präsenz:

Optional

Typ:

Dabei kann es sich um einen Schlüssel (einen von Ihnen angegebenen statischen Namen) oder um einen Wert (einen dynamischen Eintrag, der durch den Verweis auf eine Variable bestimmt wird) handeln. Alle angegebenen Fragmente werden (plus Präfix) verkettet, um den Cache-Schlüssel zu erstellen.

<KeyFragment>apiAccessToken</KeyFragment>
<KeyFragment ref="request.queryparam.client_id" />

Sie verwenden das <KeyFragment>-Element zusammen mit <Prefix> und <Scope>. Weitere Informationen finden Sie unter Mit Cache-Schlüsseln arbeiten.

Attribute

Attribut Typ Default Erforderlich Beschreibung
Ref String Nein

Die Variable, aus der der Wert abgerufen wird. Sollte nicht verwendet werden, wenn dieses Element einen Literalwert enthält.

<CacheKey>/<Prefix>-Element

Gibt den Wert an, der als Cache-Schlüsselpräfix verwendet werden soll.

<Prefix>prefix_string</Prefix>

Standard:

Präsenz:

Optional

Typ:

String

Verwenden Sie diesen Wert anstelle von <Scope>, wenn Sie einen eigenen Wert anstelle eines <Scope>-Aufzählungswerts angeben möchten. Wenn definiert, definiert <Prefix> den Cache-Schlüsselwert für Einträge, die in den Cache geschrieben werden. <Prefix>-Elementwerte überschreiben <Scope>-Elementwerte.

Sie verwenden das <Prefix>-Element zusammen mit <CacheKey> und <Scope>. Weitere Informationen finden Sie unter Mit Cache-Schlüsseln arbeiten.

<ExcludeErrorResponse>-Element

Derzeit speichert diese Richtlinie HTTP-Antworten mit einem beliebigen möglichen Statuscode im Cache. Das heißt, sowohl die Erfolgs- als auch die Fehlerantworten werden im Cache gespeichert. Beispielsweise werden Antworten mit den Statuscodes 2xx und 3xx standardmäßig im Cache gespeichert.

Setzen Sie dieses Element auf true, wenn Sie Zielantworten mit HTTP-Fehlerstatuscodes nicht im Cache speichern möchten. Nur Antworten mit Statuscodes von 200 bis 205 werden im Cache gespeichert, wenn dieses Element „true“ ist. Dies sind die einzigen HTTP-Statuscodes, als von Edge gezählt werden „Erfolg“ und Sie können diese Verknüpfung nicht ändern.

Eine Erläuterung der Antwort-Cache-Muster, in denen dieses Element hilfreich ist, finden Sie in diesem Communitybeitrag.

Hinweis:In einer zukünftigen Version wird die Standardeinstellung in "true" geändert. Siehe Apigee Versionshinweise.

<ExcludeErrorResponse>true</ExcludeErrorResponse>

Standardeinstellung:

false

Präsenz:

Optional

Typ:

Boolean

<ExpirySettings>-Element

Gibt an, wann ein Cache-Eintrag ablaufen soll. Wenn vorhanden, überschreibt <TimeoutInSeconds> sowohl <TimeOfDay> als auch <ExpiryDate>.

<ExpirySettings>
  <TimeOfDay ref="time_variable">expiration_time</TimeOfDay>
  <TimeoutInSeconds ref="duration_variable">seconds_until_expiration</TimeoutInSeconds>
  <ExpiryDate ref="date_variable">expiration_date</ExpiryDate>
</ExpirySettings>

Standardeinstellung:

Präsenz:

Erforderlich

Typ:

<ExpirySettings>/<ExpiryDate>-Element

Gibt das Datum an, an dem ein Cache-Eintrag ablaufen soll. Verwenden Sie das Format mm-dd-yyyy. Wenn dieses Element vorhanden ist, wird <ExpiryDate> vom gleichgeordneten Element <TimeoutInSeconds> überschrieben.

<ExpirySettings>
    <ExpiryDate ref="{date_variable}">expiration_date</ExpiryDate>
</ExpirySettings>

Standardeinstellung:

Präsenz:

Optional

Typ:

String

Attribute

<ExpiryDate ref="" />
Attribut Beschreibung Standard Präsenz Typ
Ref

Die Variable, aus der der Wert abgerufen wird. Sollte nicht verwendet werden, wenn dieses Element einen Literalwert enthält.

Optional String

<ExpirySettings>/<TimeOfDay>-Element

Die Tageszeit, zu der ein Cache-Eintrag ablaufen soll. Verwenden Sie das Format hh:mm:ss. Wenn dieses Element vorhanden ist, wird <TimeOfDay> vom gleichgeordneten Element <TimeoutInSeconds> überschrieben.

Geben Sie die Tageszeit im Format HH:mm:ss ein. Dabei steht HH für die Stunde im 24-Stunden-Format. Beispiel: 14:30:00 für 14:30 Uhr am Nachmittag.

In Bezug auf die Tageszeit variieren die Standardsprache und -zeitzone je nachdem, wo der Code ausgeführt wird. Das ist bei der Konfiguration der Richtlinie nicht bekannt. Informationen zum Konfigurieren der Sprache finden Sie unter Umgebungs-Cache erstellen und bearbeiten.

<ExpirySettings>
    <TimeOfDay ref="time_variable">expiration_time</TimeOfDay>
</ExpirySettings>

Standardeinstellung:

Präsenz:

Optional

Typ:

String

Attribute

Attribut Beschreibung Standard Präsenz Typ
Ref Variable mit Ablaufzeitwert. Optional String

<ExpirySettings>/<TimeoutInSec>-Element

Die Anzahl der Sekunden, nach denen ein Cache-Eintrag abläuft.

<ExpirySettings>/<TimeoutInSeconds>-Element

Die Anzahl der Sekunden, nach denen ein Cache-Eintrag abläuft. Wenn dieses Element vorhanden ist, überschreibt dieses Element seine gleichgeordneten Elemente <TimeOfDay> und <ExpiryDate>.

<ExpirySettings>
    <TimeoutInSeconds ref="duration_variable">seconds_until_expiration</TimeoutInSeconds>
</ExpirySettings>

Hinweis: Geben Sie einen Standardwert für die Zeitüberschreitung an, der verwendet werden soll, wenn "ref" keinen Wert aus der duration_variable empfängt.

Standard:

Präsenz:

Optional

Typ:

String

Attribute

Attribut Beschreibung Standard Präsenz Typ
Ref Variable mit Zeitüberschreitungswert.
Optional String

<Scope>-Element

Aufzählung, die zum Erstellen eines Präfixes für einen Cache-Schlüssel verwendet wird, wenn das Element <Prefix> nicht im Element <CacheKey> angegeben ist.

<Scope>scope_enumeration</Scope>

Standard:

"Exklusiv"

Präsenz:

Optional

Typ:

String

Mit der Einstellung <Scope> wird ein Cache-Schlüssel festgelegt, dem gemäß des Werts <Scope> etwas vorangestellt wird. Ein Cache-Schlüssel hat beispielsweise das folgende Format, wenn der Bereich auf Exclusive : orgName__envName__apiProxyName__deployedRevisionNumber__proxy|TargetName__ [ serializedCacheKey ] festgelegt ist.

Ist in <CacheKey> ein <Prefix>-Element vorhanden, hat dies vor einem <Scope>-Elementwert Vorrang. Gültige Werte sind folgende Aufzählungen.

Sie verwenden das <Scope>-Element zusammen mit <CacheKey> und <Prefix>. Weitere Informationen finden Sie unter Mit Cache-Schlüsseln arbeiten.

Zulässige Werte

Bereichswert Beschreibung
Global

Der Cache-Schlüssel wird für alle API-Proxys freigegeben, die in der Umgebung bereitgestellt werden. Der Cache-Schlüssel wird im Format orgName __ envName vorangestellt.

Wenn Sie einen <CacheKey>-Eintrag mit dem <KeyFragment>-apiAccessToken und dem Bereich <Global> definieren, wird jeder Eintrag als orgName__envName__apiAccessToken gespeichert, gefolgt vom serialisierten Wert des Zugriffstokens. Für einen API-Proxy, der in einer Umgebung mit dem Namen "Test" in einer Organisation namens "apifactory" bereitgestellt wird, werden Zugriffstoken unter folgendem Cache-Schlüssel gespeichert: apifactory__test__apiAccessToken.

Application

Der API-Proxyname wird als Präfix verwendet.

Der Cache-Schlüssel wird im Format orgName__envName__apiProxyName vorangestellt.

Proxy

Die ProxyEndpoint-Konfiguration wird als Präfix verwendet.

Der Cache-Schlüssel wird im Format orgName__envName__apiProxyName__deployedRevisionNumber__proxyEndpointName vorangestellt.

Target

Die TargetEndpoint-Konfiguration wird als Präfix verwendet.

Der Cache-Schlüssel wird im Format orgName__envName__apiProxyName__deployedRevisionNumber__targetEndpointName vorangestellt.

Exclusive

Standard. Dies ist die spezifischste Zuordnung und bedingt daher ein minimales Risiko in Sachen Namespace-Konflikten in einem bestimmten Cache.

Das Präfix gibt es in zwei Formen:

  • Wenn die Richtlinie an den Ablauf ProxyEndpoint angehängt wird, hat das Präfix das Format ApiProxyName_ProxyEndpointName.
  • Wenn die Richtlinie unter TargetEndpoint angehängt wird, hat das Präfix das Format ApiProxyName_TargetName.

Der Cache-Schlüssel wird im Format orgName__envName__apiProxyName__deployedRevisionNumber__proxyNameITargetName angehängt.

Der vollständige String kann so aussehen:

apifactory__test__weatherapi__16__default__apiAccessToken
.

<SkipCacheLookup>-Element

Definiert einen Ausdruck, der angibt, dass die Cache-Suche übersprungen und der Cache aktualisiert werden soll. Voraussetzung ist, dass der Ausdruck zur Laufzeit "true" ergibt. Weitere Informationen zur Verwendung von SkipCacheLookup finden Sie in diesem Video.

<SkipCacheLookup>variable_condition_expression</SkipCacheLookup>

Standardeinstellung:

Präsenz:

Optional

Typ:

String

Wenn im folgenden Beispiel die bypass-cache-Variable in einem eingehenden Header auf "true" gesetzt ist, wird die Cache-Suche übersprungen und der Cache wird aktualisiert.

<SkipCacheLookup>request.header.bypass-cache = "true"</SkipCacheLookup>

<SkipCachePopulation>-Element

Definiert einen Ausdruck, der bei Auswertung zur Laufzeit als „true“ angibt, dass ein Schreibvorgang in den Cache übersprungen werden soll. Weitere Informationen zur Verwendung von SkipCachePopulation finden Sie in diesem Video.

<SkipCachePopulation>variable_condition_expression</SkipCachePopulation>

Standardeinstellung:

Präsenz:

Optional

Typ:

String

Im Folgenden wird beispielsweise der Cache-Schreibvorgang übersprungen, wenn der Statuscode der Antwort 400 oder höher war:

<SkipCachePopulation>response.status.code >= 400</SkipCachePopulation>

<UseAcceptHeader>-Element

Geben Sie true an, damit der Cache-Schlüssel eines Repository-Cache-Eintrags mit Werten aus Antwort-Accept-Headern angehängt wird.

Edge verwendet die Accept, Accept-Encoding, Accept-Language und Accept-Charset-Anfrageheader bei der Berechnung des Cache-Schlüssels. Dieser Ansatz verhindert, dass ein Client einen Medientyp erhält, nach dem er nicht gefragt hat.

Angenommen, zwei Anfragen stammen von derselben URL, wobei die erste Anfrage gzip akzeptiert und die zweite nicht. Die erste Anfrage wird im Cache gespeichert und der im Cache gespeicherte Eintrag ist (wahrscheinlich) eine mit gzip komprimierte Antwort. Die zweite Anfrage liest den im Cache gespeicherten Wert und kann dann einen gzip-Eintrag an einen Client zurückgeben, der gzip nicht lesen kann.

Weitere Informationen finden Sie unter Cache-Schlüssel konfigurieren.

<UseAcceptHeader>false</UseAcceptHeader>

Standardeinstellung:

false

Präsenz:

Optional

Typ:

Boolean

<UseResponseCacheHeaders>-Element

Legen Sie true fest, damit HTTP-Antwortheader beim Festlegen der Gültigkeitsdauer (TTL) der Antwort im Cache berücksichtigt werden. Wenn dies wahr ist, berücksichtigt Edge die Werte der folgenden Antwort-Headern und vergleicht die Werte mit denen, <ExpirySettings> beim Festlegen der Gültigkeitsdauer:

  • Cache-Control s-maxage
  • Cache-Control max-age
  • Expires

Weitere Informationen finden Sie unter Ablauf von Cache-Eintrag festlegen.

<UseResponseCacheHeaders>false</UseResponseCacheHeaders>

Standardeinstellung:

false

Präsenz:

Optional

Typ:

Boolean

Verwendungshinweise

Die maximale Größe für jedes im Cache gespeicherte Objekt beträgt 256 KB. (Detaillierte Informationen dazu, wie Edge Prozesscache, siehe Cache interne Funktionen.)

Durch die Konfiguration in der ResponseCache-Richtlinie können Sie festlegen, dass Edge eine HTTP-Antwort einbindet. -Header beim Festlegen des Ablaufs von Cache-Einträgen und der Cache-Schlüssel. In diesem Abschnitt wird beschrieben, wie Sie die Richtlinie mit Headern zur Verwaltung des Cache-Ablaufs und der Cache-Schlüssel verwenden können.

Weitere Informationen dazu, wie Edge Antwortheader mit der ResponseCache-Richtlinie verarbeitet, finden Sie unter Unterstützung für HTTP-Antwortheader.

Ablauf von Cache-Eintrag festlegen

Wie auch bei der PopulateCache-Richtlinie können Sie mit dem Element <ExpirySettings> die Gültigkeitsdauer (TTL) eines Antwortcache festlegen. In der ResponseCache-Richtlinie können Sie auch Edge verwenden, Antwort-Header berücksichtigen, sofern vorhanden.

Wenn Sie Antwortheader verwenden möchten, setzen Sie den Elementwert <UseResponseCacheHeaders> auf „true“. Diese Einstellung bewirkt, dass Edge die Antwortheader berücksichtigt und sie mit dem festgelegten Wert vergleicht nach <ExpirySettings>, dann wird der niedrigste Wert zwischen den beiden verwendet. Wann? unter Berücksichtigung der Antwortheader wählt Edge den verfügbaren Wert, wie in den Folgendes:

Angenommen, eine Antwort wird mit den folgenden Werten im Cache gespeichert:

  • Kein Cache-Control s-maxage-Wert
  • Ein Cache-Control max-age-Wert von 300
  • Ein Expires-Datum in drei Tagen
  • Ein <ExpirySettings> TimeoutInSeconds-Wert von 600.

In diesem Fall wird der Wert Cache-Control max-age für die TTL verwendet, da diese unter dem Wert <ExpirySettings> liegt und kein Cache-Control s-maxage-Wert vorhanden ist, der Vorrang vor max-age hat.

Cache-Schlüssel konfigurieren

Wie auch bei Cache-Richtlinien mit allgemeinem Zweck wie der PopulateCache-Richtlinie verwenden Sie ResponseCache mit den Elementen <CacheKey> und <Scope>, um das Erstellen von Cache-Schlüsseln für Cache-Einträge zu konfigurieren. Mit ResponseCache können Sie Cache-Schlüssel auch aussagekräftiger gestalten, indem Sie festlegen, dass Antwort-Accept-Header an Schlüsselwerte angehängt werden.

Allgemeine Informationen zum Konfigurieren von Cache-Schlüsseln finden Sie unter Mit Cache-Schlüsseln arbeiten. Weitere Informationen zur Verwendung von Accept-Headern finden Sie unter <UseAcceptHeader>.

Informationen zur Cache-Verschlüsselung

Edge for Public Cloud: Der Cache wird nur in folgenden Ressourcen verschlüsselt: PCI- und mit HIPAA-Unterstützung Unternehmen. Die Verschlüsselung dieser Organisationen wird während der Bereitstellung der Organisation konfiguriert.

Ablaufvariablen

Die folgenden vordefinierten Ablaufvariablen werden erfasst, wenn eine ResponseCache-Richtlinie ausgeführt wird. Weitere Informationen zu Ablaufvariablen finden Sie in der Variablenreferenz.

Variablen Typ Berechtigung Beschreibung
responsecache.{policy_name}.cachename String Schreibgeschützt: Gibt den in der Richtlinie verwendeten Cache zurück
responsecache.{policy_name}.cachekey String Schreibgeschützt: Gibt den verwendeten Schlüssel zurück
responsecache.{policy_name}.cachehit Boolean Schreibgeschützt: TRUE, wenn die Ausführung der Richtlinie erfolgreich ist
responsecache.{policy_name}.invalidentry Boolean Schreibgeschützt: TRUE, wenn der Cache-Eintrag ungültig ist

Fehlercodes

In diesem Abschnitt werden die Fehlermeldungen und Ablaufvariablen beschrieben, die festgelegt werden, wenn diese Richtlinie einen Fehler auslöst. Dieses Informationen sind wichtig, wenn Sie Fehlerregeln für einen Proxy entwickeln. Weitere Informationen finden Sie unter Was Sie über Richtlinienfehler wissen müssen und Fehler beheben.

Fehlercode-Präfix

Laufzeitfehler

Diese Richtlinie gibt keine Laufzeitfehler aus.

Bereitstellungsfehler

Diese Fehler können auftreten, wenn Sie einen Proxy bereitstellen, der diese Richtlinie enthält.

Fehlername Ursache Problembehebung
InvalidTimeout Wenn das Element <CacheLookupTimeoutInSeconds> einer ResponseCache-Richtlinie auf eine negative Zahl gesetzt ist, schlägt das Deployment des API-Proxys fehl.
InvalidCacheResourceReference Dieser Fehler tritt auf, wenn für das Element <CacheResource> in der ResponseCache-Richtlinie ein Name angegeben ist, der in der Umgebung, in der der API-Proxy bereitgestellt wird, nicht vorhanden ist.
ResponseCacheStepAttachmentNotAllowedReq Dieser Fehler tritt auf, wenn dieselbe ResponseCache-Richtlinie an mehrere Anfragepfade innerhalb eines Ablaufs eines API-Proxys angehängt wird.
ResponseCacheStepAttachmentNotAllowedResp Dieser Fehler tritt auf, wenn dieselbe ResponseCache-Richtlinie an mehrere Antwortpfade innerhalb eines Ablaufs eines API-Proxys angehängt wird.
InvalidMessagePatternForErrorCode Dieser Fehler tritt auf, wenn das Element <SkipCacheLookup> oder <SkipCachePopulation> in einer ResponseCache-Richtlinie eine ungültige Bedingung enthält.
CacheNotFound Dieser Fehler tritt auf, wenn der in der Fehlermeldung erwähnte Cache nicht auf einer bestimmten Message Processor-Komponente erstellt wurde.

Fehlervariablen

Beispiel für eine Fehlerantwort

Schema

Jeder Richtlinientyp wird durch ein XML-Schema (.xsd) definiert. Zu Referenzzwecken sind Richtlinienschemas auf GitHub verfügbar.