Google używa technologii AI do tłumaczenia treści na Twój preferowany język. Tłumaczenia wygenerowane przez AI mogą zawierać błędy.

Obsługa nagłówków odpowiedzi HTTP

Wyświetlasz dokumentację Apigee Edge.
Przejdź do dokumentacji Apigee X. info

Z tego artykułu dowiesz się, jak Edge obsługuje nagłówki buforowania HTTP/1.1, gdy używasz zasady ResponseCache. Apigee Edge obsługuje obecnie podzbiór nagłówków i dyrektyw buforowania HTTP/1.1 (nieobsługiwane funkcje są wymienione w tym artykule) otrzymywanych z serwerów docelowych (źródłowych) backendu.

Ponadto w przypadku niektórych nagłówków Edge podejmuje działania na podstawie ich dyrektyw. W niektórych przypadkach, te nagłówki pamięci podręcznej HTTP/1.1 zastępują zachowanie określone w zasadzie ResponseCache. Jeśli na przykład serwer backendu zwraca nagłówek Cache-Control, dyrektywa s-maxage tego nagłówka może zastąpić inne ustawienia wygaśnięcia w zasadzie.

Uwaga: używanie nagłówków do wpływania na klucze pamięci podręcznej i czas życia wpisu w pamięci podręcznej Możesz skonfigurować Edge tak, aby podczas tworzenia kluczy pamięci podręcznej odpowiedzi i ustawiania czasu życia wpisu w pamięci podręcznej używał nagłówków odpowiedzi. Aby to zrobić, użyj tych elementów flagi zasady ResponseCache:

<UseResponseCacheHeaders> – gdy ta opcja jest ustawiona na true, Edge będzie uwzględniać nagłówki odpowiedzi HTTP podczas ustawiania czasu życia odpowiedzi w pamięci podręcznej. Więcej informacji znajdziesz w sekcjach "Ustawianie wygaśnięcia wpisu w pamięci podręcznej" i <UseResponseCacheHeaders> w zasadzie ResponseCache.
<UseAcceptHeader> – gdy ta opcja jest ustawiona na true, Edge będzie używać nagłówków Accept odpowiedzi do rozszerzania klucza pamięci podręcznej. Więcej informacji znajdziesz w sekcji <UseAcceptHeader> w zasadzie ResponseCache.

Nagłówek	Pomoc
Cache-Control	Obsługiwane w przypadku odpowiedzi zwracanych przez serwery źródłowe backendu, ale nie w przypadku żądań klientów. Edge obsługuje podzbiór dyrektyw.
Wygasa	Obsługiwane. Można je zastąpić.
Tagi encji (ETag)	Określone zachowanie w przypadku If-Match i If-None-Match.
If-Modified-Since	W przypadku żądań GET nagłówek jest przekazywany do serwera pierwotnego, 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 przypadku odpowiedzi zwracanych przez serwery pierwotne backendu (specyfikacja HTTP/1.1 zezwala na używanie nagłówków Cache-Control zarówno w żądaniach klientów, jak i w odpowiedziach serwerów pierwotnych). Serwery źródłowe mogą obejmować zarówno punkty końcowe docelowe zdefiniowane w serwerze proxy interfejsu API Apigee Edge, jak i te utworzone za pomocą wywołań interfejsu TargetServer API.

Ograniczenia obsługi Cache-Control

Apigee Edge obsługuje podzbiór funkcji nagłówka odpowiedzi Cache-Control zdefiniowanych w specyfikacji HTTP/1.1. Uwaga:

Apigee Edge nie obsługuje nagłówków Cache-Control, które docierają z przychodzącymi żądaniami klientów.
Apigee Edge obsługuje tylko koncepcję pamięci podręcznych publicznych. (Zgodnie ze specyfikacją HTTP Cache-Control może być publiczny (współdzielony) lub prywatny (dla jednego użytkownika)).
Apigee Edge obsługuje tylko podzbiór Cache-Control dyrektyw odpowiedzi w specyfikacji HTTP/1.1. Więcej informacji znajdziesz w sekcji 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 znajdziesz informacje o obsłudze dyrektyw nagłówka odpowiedzi HTTP Cache-Control w Apigee Edge.

Szczegółowe informacje o dyrektywach wymienionych w tym artykule 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 zasada ResponseCache ma ustawiony element `<UseResponseCacheHeaders>` na `true`, odpowiedź może być przechowywana 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 `Expires` nagłówek. Może też zostać zastąpiona przez element zasady `<ExpirySettings>`. Więcej informacji znajdziesz w sekcjach „Ustawianie wygaśnięcia wpisu w pamięci podręcznej” i `<UseResponseCacheHeaders>` w zasadzie ResponseCache. Uwaga: treści przechowywane w pamięci podręcznej za pomocą zasady ResponseCache zachowają wartość max-age ustawioną przez źródło. Oznacza to, że po pobraniu z pamięci podręcznej treści mogą być starsze niż sugeruje wartość max-age (starsze niż wie klient).
`must-revalidate`	Nieobsługiwane. Wszystkie wpisy w pamięci podręcznej są usuwane przez Apigee Edge natychmiast po wygaśnięciu.
`no-cache`	Edge przechowuje w pamięci podręcznej odpowiedź źródłową, ale przed użyciem jej do obsługi kolejnych żądań klientów musi zostać ponownie zweryfikowana przez serwer pierwotny. Ta 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 pozwala zaoszczędzić czas przetwarzania wymagany do zwrócenia całej odpowiedzi. Jeśli serwer pierwotny zwróci pełną odpowiedź, zastąpi ona istniejący wpis w pamięci podręcznej. Wszystkie nazwy pól określone w tej dyrektywie są ignorowane. Uwaga: nagłówek HTTP/1.0 `Pragma: no-cache` jest traktowany jako odpowiednik `Cache-Control: no-cache`.
`no-store`	Nieobsługiwane.
`no-transform`	Nieobsługiwane.
`private`	Nieobsługiwane. Jeśli ta dyrektywa zostanie odebrana, odpowiedź źródłowa nie zostanie zapisana w pamięci podręcznej. Wszystkie nazwy pól są ignorowane.
`proxy-revalidate`	Nieobsługiwane. Wszystkie wpisy w pamięci podręcznej są usuwane przez Apigee Edge natychmiast po wygaśnięciu.
`public`	Edge przechowuje w pamięci podręcznej odpowiedź źródłową, nawet jeśli inne dyrektywy wskazują inaczej. 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 zasada ResponseCache ma ustawiony element `<UseResponseCacheHeaders>` na `true`, odpowiedź może być przechowywana 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 zostać zastąpiona przez element `<ExpirySettings>` zasady. Więcej informacji znajdziesz w sekcjach „Ustawianie wygaśnięcia wpisu w pamięci podręcznej” i `<UseResponseCacheHeaders>` w zasadzie ResponseCache. Uwaga: treści przechowywane w pamięci podręcznej za pomocą zasady ResponseCache zachowają wartość s-maxage ustawioną przez źródło. Oznacza to, że po pobraniu z pamięci podręcznej treści mogą być starsze niż sugeruje wartość s-maxage (starsze niż wie klient).

Wygasa

Gdy flaga UseResponseCacheHeaders w zasadzie ResponseCache jest ustawiona na true, Edge może używać nagłówka Expires do określania czasu życia (TTL) wpisu w pamięci podręcznej. Ten nagłówek określa datę i godzinę, po których wpis w pamięci podręcznej odpowiedzi jest uznawany za nieaktualny. Ten nagłówek umożliwia serwerom sygnalizowanie, kiedy można zwrócić wartość z pamięci podręcznej na podstawie sygnatury czasowej.

Uwaga: dyrektywy nagłówka Cache-Control max-age i s-maxage mają pierwszeństwo przed nagłówkiem Expires i go zastępują. Więcej informacji znajdziesz w sekcjach "Ustawianie wygaśnięcia wpisu w pamięci podręcznej" i <UseResponseCacheHeaders> w zasadzie ResponseCache.

Dopuszczalne formaty daty w nagłówku Expires są opisane w specyfikacji HTTP/1.1. Na przykład:

Expires: Thu, 01 Dec 1994 16:00:00 GMT

Szczegółowe informacje o formatach daty i godziny HTTP znajdziesz w sekcji Formaty daty i godziny w specyfikacji HTTP/1.1.

Uwaga: chociaż sekcja 14.21 specyfikacji wskazuje, że wartość Expires większa niż rok w przyszłości oznacza, że wpis w pamięci podręcznej nigdy nie wygaśnie, Apigee interpretuje taką wartość jako wskazanie, że wpis powinien być przechowywany w pamięci podręcznej do określonej daty i godziny.

Więcej informacji o nagłówku Expires znajdziesz w sekcji Definicje pól nagłówka w specyfikacji HTTP/1.1.

ETag

Tag encji (ETag) to identyfikator powiązany z żądanym zasobem. Za pomocą tagu ETag a serwer może określić, czy żądany zasób i powiązany z nim zasób w pamięci podręcznej są zgodne. Serwer może na przykład ponownie zapisać odpowiedź w pamięci podręcznej, jeśli nie pasuje ona do tego, co jest obecnie w pamięci podręcznej. Jeśli tagi ETag są zgodne, może zwrócić zasób z pamięci podręcznej.

Gdy punkt końcowy docelowy wysyła do Edge odpowiedź z tagiem ETag, Edge zapisuje ten tag w pamięci podręcznej wraz z odpowiedzią.

Więcej informacji o tagach encji znajdziesz w sekcji Parametry protokołu w specyfikacji HTTP/1.1.

If-Match

W przypadku nagłówka żądania If-Match encja w pamięci podręcznej jest aktualna, jeśli tag ETag w nagłówku jest zgodny z tagiem ETag w pamięci podręcznej. Wszystkie żądania inne niż GET, które określają nagłówek If-Match są przekazywane do serwera pierwotnego, aby zapewnić, że wszystkie mechanizmy buforowania źródłowego będą miały szansę przetworzyć żądanie.

Więcej informacji o If-Match znajdziesz w sekcji Definicje pól nagłówka w specyfikacji HTTP/1.1.

Jeśli Edge otrzyma przychodzące żądanie GET od klienta, które zawiera nagłówek If-Match:

Jeśli	Wtedy
Nagłówek `If-Match` określa co najmniej 1 tag ETag.	Apigee Edge pobiera wszystkie niewygasłe wpisy w pamięci podręcznej dla określonego zasobu i porównuje wszystkie silne tagi ETag w tych wpisach z tagami określonymi w `If-Match` nagłówku. Jeśli zostanie znalezione dopasowanie, zwracany jest wpis w pamięci podręcznej. W przeciwnym razie żądanie jest przekazywane do serwera pierwotnego.
Nagłówek `If-Match` określa „*”.	Żądanie jest przekazywane do serwera pierwotnego, aby zapewnić, że wszystkie mechanizmy buforowania serwera pierwotnego 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 klientowi musi on zostać ponownie zweryfikowany przez serwer pierwotny.
Tagi ETag pochodzą z serwera pierwotnego.	Tag ETag jest zwracany do klienta bez zmian.

If-None-Match

W przypadku nagłówka If-None-Match encja w pamięci podręcznej jest aktualna, jeśli tag ETag w nagłówku nie jest zgodny z tagiem ETag w pamięci podręcznej. Żądania inne niż GET, które zawierają ten nagłówek, są przekazywane do serwera pierwotnego.

Jeśli Edge otrzyma przychodzące żądanie GET z tym nagłówkiem:

Jeśli	Wtedy
Nagłówek `If-None-Match` określa co najmniej 1 tag ETag.	Apigee Edge pobiera wszystkie niewygasłe wpisy w pamięci podręcznej dla określonego identyfikatora URI i porównuje wszystkie silne tagi ETag w tych wpisach z tagami określonymi w `If-None-Match` nagłówku. Jeśli zostanie znalezione dopasowanie, Edge zwraca stan 304 Not Modified. Jeśli nie zostanie znalezione dopasowanie, Edge przekazuje żądanie do serwera pierwotnego.
Nagłówek `If-None-Match` określa „*”, a dla żądanego identyfikatora URI istnieje niewygasły wpis w pamięci podręcznej.	Edge zwraca stan 304 Not Modified.
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 klientowi przez Edge musi on zostać ponownie zweryfikowany przez serwer pierwotny.
Edge otrzymuje tag ETag z serwera pierwotnego.	Tag ETag jest zwracany do klienta bez zmian.

If-Modified-Since

Jeśli Apigee Edge otrzyma nagłówek If-Modified-Since w żądaniu GET, jest on przekazywany do serwera pierwotnego, nawet jeśli istnieje prawidłowy wpis w pamięci podręcznej.

Dzięki temu uwzględniane są wszystkie aktualizacje zasobu, które nie przeszły przez Apigee Edge i są uwzględniane. Jeśli serwer pierwotny zwróci nową encję, Edge zastąpi istniejący wpis w pamięci podręcznej nową wartością. Jeśli serwer zwróci stan 304 Not Modified, Edge zwróci wartość odpowiedzi, jeśli nagłówek Last-Modified odpowiedzi w pamięci podręcznej wskazuje, że nie uległa ona zmianie.

Accept-Encoding

Gdy żądanie przychodzące zawiera nagłówek Accept-Encoding z wartościami gzip, deflate lub compress, serwer pierwotny odpowiada skompresowanymi danymi. Gdy kolejne żądania przychodzą bez nagłówków Accept-Encoding, oczekują one nieskompresowanej odpowiedzi. Mechanizm buforowania odpowiedzi Apigee może wysyłać odpowiedzi skompresowane i nieskompresowane w zależności od nagłówków przychodzących bez konieczności powrotu do serwera pierwotnego.

Możesz dołączać wartości nagłówka Accept do kluczy pamięci podręcznej, aby klucze były bardziej znaczące dla każdego elementu w pamięci podręcznej. Więcej informacji znajdziesz w sekcji "Konfigurowanie klucza pamięci podręcznej" w zasadzie ResponseCache.