Ta strona została przetłumaczona przez Cloud Translation API.

Obsługa nagłówków odpowiedzi HTTP

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje

W tym temacie opisano, jak Edge obsługuje nagłówki buforowania HTTP/1.1 podczas korzystania z zasady ResponseCache. Apigee Edge obecnie obsługuje podzbiór nagłówków i dyrektyw buforowania HTTP/1.1 (nieobsługiwane funkcje są wymienione w tym temacie) otrzymanych z docelowych serwerów backendu (źródłowych).

Dodatkowo Edge w niektórych nagłówkach podejmuje działania zgodnie z własnymi dyrektywami. W niektórych przypadkach nagłówki pamięci podręcznej HTTP/1.1 zastępują zachowanie określone w zasadzie ResponseCache. Jeśli na przykład nagłówek Cache-Control jest zwracany z serwera backendu, dyrektywa s-maxage nagłówka może potencjalnie zastąpić inne ustawienia wygaśnięcia określone w zasadzie.

Uwaga: używanie nagłówków do wpływu na klucze pamięci podręcznej i TTL wpisów pamięci podręcznej Edge może używać nagłówków odpowiedzi podczas tworzenia kluczy pamięci podręcznej odpowiedzi i ustawiania wartości TTL wpisów pamięci podręcznej. Aby to zrobić, użyj następujących elementów flagi zasady ResponseCache:

<UseResponseCacheHeaders> – gdy ma wartość true, Edge uwzględnia nagłówki odpowiedzi HTTP podczas ustawiania „czasu życia danych” (TTL) odpowiedzi w pamięci podręcznej. Więcej informacji znajdziesz w sekcjach „Ustawianie czasu ważności wpisu z pamięci podręcznej” i sekcji <UseResponseCacheHeaders> w sekcjach dotyczących pamięci podręcznej odpowiedzi.
<UseAcceptHeader> – gdy ma wartość true, Edge używa nagłówków Accept odpowiedzi do rozszerzania klucza pamięci podręcznej. Więcej informacji znajdziesz w opisie <UseAcceptHeader> w zasadzie buforowania odpowiedzi.

Nagłówek	Pomoc
Kontrola pamięci podręcznej	Obsługiwane w przypadku odpowiedzi zwracanych z serwerów początkowych backendu, ale nie w żądaniach klienta. Edge obsługuje podzbiór dyrektyw.
Wygasa	Obsługiwane. Można ją zastąpić.
Tagi encji (ETag)	Specjalne działanie właściwości If-Match i If-None-Match.
If-Modified-Modified	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 (Akceptuj kodowanie)	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 z serwerów początkowych backendu (specyfikacja HTTP/1.1 zezwala na nagłówki Cache-Control zarówno w żądaniach klientów, jak i odpowiedziach serwera pierwotnego). Serwery źródłowe mogą zawierać zarówno docelowe punkty końcowe zdefiniowane w serwerze proxy Apigee Edge API, jak i te utworzone przy użyciu 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 przychodzą z przychodzącymi żądaniami klienta.
Apigee Edge obsługuje tylko pojęcie publicznych pamięci podręcznych. Zgodnie ze specyfikacją HTTP Cache-Control może być publiczny (udostępniony) lub prywatny (pojedynczy użytkownik).
Apigee Edge obsługuje tylko podzbiór dyrektyw odpowiedzi Cache-Control w specyfikacji HTTP/1.1. Więcej informacji znajdziesz w sekcji Obsługa dyrektyw nagłówków odpowiedzi Cache-Control.

Obsługa dyrektyw nagłówka odpowiedzi Cache-Control

Apigee obsługuje podzbiory dyrektyw ze specyfikacji HTTP/1.1 w odpowiedziach z serwerów źródłowych. W tabeli poniżej opisujemy obsługę przez Apigee Edge dyrektyw nagłówka odpowiedzi HTTP Cache-Control.

Więcej informacji o wymienionych tutaj 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 zasada ResponseCache ustawia element `<UseResponseCacheHeaders>` na `true`, odpowiedź może być przechowywana w pamięci podręcznej przez liczbę sekund określoną przez tę dyrektywę. Ta dyrektywa została zastąpiona przez dyrektywę `s-maxage` i zastępuje nagłówek `Expires`. Można ją też zastąpić elementem `<ExpirySettings>` zasady. Więcej informacji znajdziesz w sekcjach „Ustawianie ważności wpisu z pamięci podręcznej” i `<UseResponseCacheHeaders>` w sekcji Zasady dotyczące buforowania odpowiedzi. Uwaga: zawartość przechowywana w pamięci podręcznej przy użyciu zasady ResponseCache zachowa wartość maksymalną ustawioną przez jej źródło. Oznacza to, że po pobraniu treści z pamięci podręcznej treść może być starsza niż sugeruje wartość atrybutu max-age (starsza niż wie klient).
`must-revalidate`	Nieobsługiwane. Wszystkie wpisy pamięci podręcznej są usuwane przez Apigee Edge natychmiast po wygaśnięciu.
`no-cache`	Edge zapisuje w pamięci podręcznej odpowiedź źródła, ale przed użyciem musi zostać ponownie zweryfikowana na serwerze pierwotnym w celu spełnienia kolejnych żądań klienta. Ta reguła pozwala źródłom zwracać odpowiedź 304 (nie zmodyfikowano), aby wskazać, że odpowiedź ma być zwracana z pamięci podręcznej, co pozwala zapisać proces przetwarzania wymagany do zwrócenia całej odpowiedzi. Jeśli serwer pierwotny zwróci pełną odpowiedź, zastąpi istniejący wpis 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. W przypadku otrzymania tej dyrektywy odpowiedź dotycząca źródła nie jest przechowywana w pamięci podręcznej. Wszystkie nazwy pól są ignorowane.
`proxy-revalidate`	Nieobsługiwane. Wszystkie wpisy pamięci podręcznej są usuwane przez Apigee Edge natychmiast po wygaśnięciu.
`public`	Edge zapisuje w pamięci podręcznej odpowiedź dotyczącą źródła, nawet jeśli inne dyrektywy wskazują inaczej. Zgodnie ze specyfikacją HTTP/1.1 jedynym wyjątkiem od tej reguły jest sytuacja, w której odpowiedź zawiera nagłówek autoryzacji.
`s-maxage`	Jeśli zasada ResponseCache ustawia element `<UseResponseCacheHeaders>` na `true`, odpowiedź może być przechowywana w pamięci podręcznej przez liczbę sekund określoną przez tę dyrektywę. Zastępuje ona dyrektywę `max-age` i nagłówek `Expires`. Można ją zastąpić elementem `<ExpirySettings>` zasady. Więcej informacji znajdziesz w sekcjach „Ustawianie ważności wpisu z pamięci podręcznej” i `<UseResponseCacheHeaders>` w sekcji Zasady dotyczące buforowania odpowiedzi. Uwaga: treść zapisana w pamięci podręcznej za pomocą zasady ResponseCache zachowa wartość s-maxage ustawioną przez jej źródło. Oznacza to, że po pobraniu treści z pamięci podręcznej treść może być starsza, niż sugeruje jej wartość s-maxage (starsza niż wie klient).

Wygasa

Gdy flaga UseResponseCacheHeaders w zasadzie ResponseCache jest ustawiona na true, Edge może użyć nagłówka Expires do określenia czasu życia wpisu 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 zasygnalizować, 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 zastępują go. Więcej informacji znajdziesz w sekcjach „Ustawianie ważności wpisu z pamięci podręcznej” i <UseResponseCacheHeaders> w sekcji Zasady dotyczące buforowania odpowiedzi.

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

Data wygaśnięcia: czw, 01 gru 1994 r., godz. 16:00:00 czasu GMT

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

Uwaga: chociaż z sekcji 14.21 specyfikacji wynika, że wartość Expires wybiegająca ponad rok w przyszłość oznacza, że wpis w pamięci podręcznej nigdy nie wygasa, Apigee zinterpretuje taką wartość w sposób, który oznacza, ż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ą typu ETag serwer może określić, czy żądany zasób jest zgodny z zasobem powiązanym z pamięcią podręczną. Serwer może na przykład ponownie zapisać odpowiedź w pamięci podręcznej, jeśli nie będzie ona zgodna z tym, co jest aktualnie przechowywane w pamięci podręcznej. Może zwrócić zasób z pamięci podręcznej, jeśli pasują do identyfikatorów ETag.

Gdy docelowy punkt końcowy wysyła odpowiedź z ETag z powrotem do Edge, Edge przechowuje ETag 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.

Jeśli dopasowanie

Dzięki nagłówkowi żądania If-Match encja z pamięci podręcznej jest aktualna, jeśli ETag w nagłówku jest zgodny z elementem ETag przechowywany 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ć możliwość przetworzenia żądania przez infrastrukturę pamięci masowej źródła.

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

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

Jeśli	Potem
Nagłówek `If-Match` zawiera co najmniej 1 tag ETag	Apigee Edge pobiera wszystkie niewygasłe wpisy pamięci podręcznej dla określonego zasobu i porównuje wszystkie silne tagi ETag w tych wpisach z pamięci podręcznej z tymi określonymi w nagłówku `If-Match`. W przypadku znalezienia dopasowania zwracany jest wpis w pamięci podręcznej. W przeciwnym razie żądanie jest przekazywane do serwera pierwotnego.
Nagłówek `If-Match` zawiera znak „*”.	Żądanie jest przekazywane do serwera pierwotnego, aby zapewnić, że wszystkie obiekty buforujące źródła mają szansę na przetworzenie żądania
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 on zostać ponownie zweryfikowany przez serwer pierwotny
Tagi ETag pochodzą z serwera pierwotnego.	Parametr ETag jest zwracany do klienta w niezmienionej postaci

Jeśli-nie-dopasowanie

Dzięki nagłówku If-None-Match encja zapisana w pamięci podręcznej jest aktualna, jeśli element ETag w nagłówku nie pasuje do zapisanego w pamięci podręcznej tagu ETag. Żądania inne niż GET zawierające ten nagłówek są przekazywane do serwera pierwotnego.

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

Jeśli	Potem
Nagłówek `If-None-Match` zawiera co najmniej 1 tag ETag	Apigee Edge pobiera wszystkie niewygasłe wpisy pamięci podręcznej dla określonego identyfikatora URI i porównuje wszystkie silne tagi ETag w tych wpisach z pamięci podręcznej z tymi określonymi w nagłówku `If-None-Match`. Jeśli znajdzie dopasowanie, Edge zwraca stan 304 Nie zmodyfikowano. Jeśli nie zostanie znalezione dopasowanie, Edge przekazuje żądanie do serwera pierwotnego.
Nagłówek `If-None-Match` zawiera znak „*” i istnieje istniejący wpis w pamięci podręcznej dotyczący żądanego identyfikatora URI	Edge zwraca stan 304 Nie zmodyfikowano.
Znaleziono wpis w pamięci podręcznej o tym samym identyfikatorze URI żądania, ale zawierający tylko słabe tagi ETag	Wpis musi zostać ponownie zweryfikowany przez serwer pierwotny, zanim Edge zwróci go do klienta
Edge otrzymuje ETag z serwera pierwotnego	Parametr ETag jest zwracany do klienta w niezmienionej postaci

Jeśli-zmodyfikowano-od

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

Dzięki temu uwzględnione są wszystkie aktualizacje zasobu, które nie zostały przekazane przez Apigee Edge. Jeśli serwer pierwotny zwróci nową encję, Edge zastępuje istniejący wpis pamięci podręcznej nową wartością. Jeśli serwer zwraca stan 304 (Nie zmodyfikowano), Edge zwraca wartość odpowiedzi, jeśli nagłówek Last-Modified odpowiedzi z pamięci podręcznej wskazuje, że odpowiedź nie została zmieniona.

Akceptuj kodowanie

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

Do kluczy pamięci podręcznej możesz dołączyć wartości nagłówków Accept, aby klucze były bardziej zrozumiałe dla każdego elementu zapisanego w pamięci podręcznej. Więcej informacji znajdziesz w sekcji „Konfigurowanie klucza pamięci podręcznej” artykułu Zasady dotyczące buforowania odpowiedzi.