Obsługa nagłówków odpowiedzi HTTP

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-MatchIf-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 <UseResponseCacheHeaders> ma wartość true, odpowiedź może zostać zapisana w pamięci podręcznej przez liczbę sekund określoną przez tę dyrektywę.

Ta dyrektywa jest zastępowana przez dyrektywę s-maxage i zastępuje nagłówek Expires. Może ona też zostać zastąpiona przez element <ExpirySettings> w zasadzie. Więcej informacji znajdziesz w sekcji „Ustawianie czasu ważności wpisu w pamięci podręcznej” i <UseResponseCacheHeaders>zasadach dotyczących pamięci podręcznej odpowiedzi.

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 <UseResponseCacheHeaders> ma wartość true, odpowiedź może zostać zapisana w pamięci podręcznej przez liczbę sekund określoną przez tę dyrektywę.

Ta dyrektywa zastępuje dyrektywę max-age i nagłówek Expires. Może ona zostać zastąpiona przez element <ExpirySettings> w zasadach. Więcej informacji znajdziesz w sekcji „Ustawianie czasu ważności wpisu w pamięci podręcznej” i <UseResponseCacheHeaders>zasadach dotyczących pamięci podręcznej odpowiedzi.

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
  1. Apigee Edge pobiera wszystkie niewygasłe wpisy w pamięci podręcznej dla określonego zasobu i porównuje wszystkie silne tagi ETag tych wpisów z tymi określonymi w nagłówku If-Match.
  2. Jeśli zostanie znalezione dopasowanie, zwrócony zostanie wpis w pamięci podręcznej.
  3. W przeciwnym razie żądanie jest przekazywane do serwera źródłowego.
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
  1. Apigee Edge pobiera wszystkie niewygasłe wpisy w pamięci podręcznej dla podanego identyfikatora URI i porównuje silne tagi ETag w tych wpisach z tagami określonymi w nagłówku If-None-Match.
  2. Jeśli zostanie znalezione dopasowanie, Edge zwróci stan 304 Not Modified. Jeśli nie zostanie znalezione żadne dopasowanie, Edge przekaże żądanie do serwera źródłowego.

Nagłówek If-None-Match zawiera wartość „*”, a żądany identyfikator URI ma niewygasły wpis w pamięci podręcznej.

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.