Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje
W tym temacie opisujemy, jak Edge obsługuje nagłówki pamięci podręcznej HTTP/1.1, gdy używasz reguły ResponseCache. Apigee Edge obsługuje obecnie podzbiór nagłówków i dyrektyw pamięci podręcznej HTTP/1.1 (nieobsługiwane funkcje są wymienione w tym temacie), które są otrzymywane z serwerów docelowych (źródłowych) zaplecza.
Ponadto w przypadku niektórych nagłówków Edge wykonuje działania na podstawie ich instrukcji. W niektórych przypadkach te nagłówki pamięci podręcznej HTTP/1.1 zastępują dowolne zachowanie określone w zasadach dotyczących pamięci podręcznej odpowiedzi.
Jeśli na przykład nagłówek Cache-Control
jest zwracany przez serwer backendu, możesz ustawić w nim dyrektywę s-maxage
, która może zastąpić inne ustawienia ważności w zasadach.
Nagłówek | Pomoc |
---|---|
Cache-Control | Obsługiwane w przypadku odpowiedzi zwracanych przez serwery pochodzenia backendu, ale nie w przypadku żądań klienta. Edge obsługuje podzbiór dyrektyw. |
Wygasa | Obsługiwane. Może być zastąpione. |
Tagi obiektów (ETags) | Specyficzne działanie w przypadku nagłówków If-Match i If-None-Match. |
If-Modified-Since | W przypadku żądań GET nagłówek jest przekazywany do serwera źródłowego, nawet jeśli istnieje prawidłowy wpis w pamięci podręcznej. |
Accept-Encoding | Edge wysyła odpowiedzi skompresowane lub nieskompresowane w zależności od nagłówków przychodzących. |
Cache-Control
Apigee Edge obsługuje nagłówek Cache-Control
tylko w odpowiedziach zwracanych przez serwery źródłowe zaplecza (specyfikacja HTTP/1.1 zezwala na nagłówki Cache-Control
zarówno w żądaniach klienta, jak i w odpowiedziach serwera źródłowego). Serwery źródłowe mogą zawierać zarówno punkty końcowe docelowe zdefiniowane w serwerze proxy interfejsu Apigee Edge API, jak i punkty końcowe utworzone za pomocą wywołań interfejsu TargetServer API.
Ograniczenia obsługi informacji Cache-Control
Apigee Edge obsługuje podzbiór możliwości nagłówków odpowiedzi Cache-Control
zdefiniowanych w specyfikacji HTTP/1.1. Uwaga:
- Apigee Edge nie obsługuje nagłówków
Cache-Control
, które docierają z żądaniami od klientów. - Apigee Edge obsługuje tylko pojęcie publicznych pamięci podręcznych. (Według specyfikacji HTTP
Cache-Control
może być publiczny (udostępniony) lub prywatny (dla jednego użytkownika).) - Apigee Edge obsługuje tylko podzbiór dyrektyw odpowiedzi
Cache-Control
w specyfikacji HTTP/1.1. Szczegółowe informacje znajdziesz w artykule Obsługa dyrektyw nagłówka odpowiedzi Cache-Control.
Obsługa dyrektyw nagłówka odpowiedzi Cache-Control
Apigee obsługuje podzbiór dyrektyw ze specyfikacji HTTP/1.1 w odpowiedziach z serwerów źródłowych. W tabeli poniżej opisano obsługę przez Apigee Edge dyrektyw nagłówka odpowiedzi HTTP Cache-Control.
Więcej informacji o wymienionych tu dyrektywach znajdziesz w sekcji Cache-Control w specyfikacji HTTP/1.1.
Dyrektywa Cache-Control | Jak Apigee Edge przetwarza dyrektywę |
cache-extension |
Nieobsługiwane. |
max-age |
Jeśli w zasadach dotyczących pamięci podręcznej odpowiedzi element Ta dyrektywa jest zastępowana przez dyrektywę |
must-revalidate |
Nieobsługiwane. Wszystkie wpisy w pamięci podręcznej są usuwane przez Apigee Edge, gdy tylko wygasną. |
no-cache |
Edge przechowuje w pamięci podręcznej odpowiedź źródłową, ale przed użyciem do obsługi kolejnych żądań klienta musi zostać ponownie zweryfikowana przez serwer źródłowy. To reguła pozwala źródłu zwrócić odpowiedź 304 Not Modified, aby wskazać, że odpowiedź powinna zostać zwrócona z pamięci podręcznej, co pozwoli zaoszczędzić przetwarzanie wymagane do zwrócenia całej odpowiedzi. Jeśli serwer źródłowy zwróci pełną odpowiedź, zastąpi ona istniejący wpis w pamięci podręcznej. Nazwy pól określone za pomocą tej dyrektywy są ignorowane. |
no-store |
Nieobsługiwane. |
no-transform |
Nieobsługiwane. |
private |
Nieobsługiwane. Jeśli otrzymano tę dyrektywę, odpowiedź źródłowa nie jest zapisywana w pamięci podręcznej. Nazwy pól są ignorowane. |
proxy-revalidate |
Nieobsługiwane. Wszystkie wpisy w pamięci podręcznej są usuwane przez Apigee Edge, gdy tylko wygasną. |
public |
Edge przechowuje w pamięci podręcznej odpowiedź źródła, nawet jeśli inne dyrektywy wskazują na coś innego. Zgodnie ze specyfikacją HTTP/1.1 jedynym wyjątkiem od tej reguły jest sytuacja, gdy odpowiedź zawiera nagłówek Authorization. |
s-maxage |
Jeśli w zasadach dotyczących pamięci podręcznej odpowiedzi element Ta dyrektywa zastępuje dyrektywę |
Wygasa
Gdy flaga UseResponseCacheHeaders
w zasadach dotyczącej pamięci podręcznej odpowiedzi ma wartość true
, przeglądarka Edge może użyć nagłówka Expires
do określenia czasu życia danych (TTL) elementu w pamięci podręcznej. Ten nagłówek określa datę i godzinę, po której wpis w pamięci podręcznej odpowiedzi jest uważany za nieaktualny. Ten nagłówek pozwala serwerom sygnalizować, kiedy można zwrócić wartość z bufora podręcznego na podstawie sygnatury czasowej.
Dopuszczalne formaty daty w nagłówku Expires
są opisane w specyfikacji HTTP/1.1. Na przykład:
Wygasa: czw. 1 grudnia 1994 r., 16:00:00 czasu GMT
Szczegółowe informacje o formatach daty i godziny w protokole HTTP znajdziesz w sekcji Formaty daty i godziny w specyfikacji HTTP/1.1.
Więcej informacji o nagłówku Expires
znajdziesz w definicjach pól nagłówka w specyfikacji HTTP/1.1.
ETag
Tag elementu (ETag) to identyfikator powiązany z żądanym zasobem. Korzystając z tagu ETag, serwer może określić, czy żądany zasób i powiązany zasób z pamięci podręcznej są zgodne. Na przykład serwer może ponownie zapisać odpowiedź w pamięci podręcznej, jeśli nie pasuje ona do tego, co jest obecnie w niej. Jeśli tagi ETagi są zgodne, może zwrócić zasób z pamięci podręcznej.
Gdy docelowy punkt końcowy wysyła odpowiedź z eTagiem z powrotem do przeglądarki Edge, ta zapisuje eTaga w pamięci podręcznej wraz z odpowiedzią.
Więcej informacji o tagach jednostek znajdziesz w sekcji Parametry protokołu w specyfikacji HTTP/1.1.
If-Match
W przypadku nagłówka żądania If-Match
element w pamięci podręcznej jest aktualny, jeśli ETag w nagłówku jest zgodny z ETagiem w pamięci podręcznej. Żądania inne niż GET, które zawierają nagłówek If-Match
, są przekazywane do serwera źródłowego, aby zapewnić, że wszelkie mechanizmy pamięci podręcznej źródła będą mogły przetworzyć żądanie.
Więcej informacji o If-Match
znajdziesz w definicjach pól nagłówka w specyfikacji HTTP/1.1.
Jeśli Edge otrzyma od klienta przychodzące żądanie GET z nagłówkiem If-Match
:
Jeśli | Wtedy |
---|---|
Nagłówek If-Match określa co najmniej 1 tag ETag |
|
Nagłówek If-Match określa wartość „*”. |
Żądanie jest przekazywane do serwera źródłowego, aby zapewnić, że wszystkie urządzenia do pamięci podręcznej źródła będą mogły przetworzyć żądanie. |
znaleziono wpis w pamięci podręcznej z tym samym identyfikatorem URI żądania, ale zawiera on tylko słabe tagi ETag | Przed zwróceniem wpisu do klienta musi zostać ponownie zweryfikowany przez serwer źródłowy. |
ETagi pochodzą z serwera źródłowego. | ETag jest zwracany bez zmian do klienta. |
If-None-Match
W przypadku nagłówka If-None-Match
element w pamięci podręcznej jest aktualny, jeśli tag E w nagłówku nie jest zgodny z tagiem E w pamięci podręcznej. Żądania inne niż GET, które zawierają ten nagłówek, są przekazywane do serwera źródłowego.
Jeśli Edge otrzyma żądanie GET z tym nagłówkiem:
Jeśli | Wtedy |
---|---|
Nagłówek If-None-Match określa co najmniej 1 tag ETag |
|
Nagłówek |
Edge zwraca stan 304 Nie zmodyfikowano |
znaleziono wpis w pamięci pod tym samym identyfikatorem URI żądania, ale zawiera on tylko słabe tagi ETag; | Przed zwróceniem wpisu do klienta przez Edge musi on zostać ponownie zweryfikowany przez serwer źródłowy. |
Urządzenie brzegowe otrzymuje ETag od serwera źródłowego | ETag jest zwracany bez zmian do klienta. |
If-Modified-Since
Jeśli Apigee Edge otrzyma nagłówek If-Modified-Since
w żądaniu GET, zostanie on przekazany serwerowi źródłowemu, nawet jeśli istnieje prawidłowy wpis w pamięci podręcznej.
Dzięki temu uwzględniane są wszystkie aktualizacje zasobu, który nie przeszedł przez Apigee Edge. Jeśli serwer źródłowy zwróci nowy element, Edge zastąpi dotychczasowy wpis w pamięci podręcznej nową wartością. Jeśli serwer zwraca stan 304 Niezmieniono, Edge zwraca wartość odpowiedzi, jeśli nagłówek Last-Modified
odpowiedzi z pamięci podręcznej wskazuje, że nie zmieniono jej treści.
Accept-Encoding
Gdy żądanie przychodzące zawiera nagłówek Accept-Encoding
o wartości gzip
, deflate
lub compress
, serwer źródłowy odpowiada danymi skompresowanymi. Gdy kolejne żądania nie zawierają nagłówków Accept-Encoding
, oczekują odpowiedzi bez kompresji. Mechanizm buforowania odpowiedzi Apigee umożliwia wysyłanie zarówno skompresowanych, jak i nieskompresowanych odpowiedzi w zależności od nagłówków przychodzących bez wracania do serwera źródłowego.
Wartości nagłówka Accept możesz dołączać do kluczy pamięci podręcznej, aby nadać im większy sens w przypadku każdego elementu w pamięci podręcznej. Więcej informacji znajdziesz w sekcji „Konfigurowanie klucza pamięci podręcznej” w zasadach dotyczących pamięci podręcznej odpowiedzi.