Ustaw Vary na nazwy nagłówków żądania, których serwer używa do wyboru reprezentacji publicznej strony. Na Macu testuj po jednym nagłówku naraz, porównuj zwrócony dokument i metadane oraz sprawdź domyślną odpowiedź przed zmianą konfiguracji.

Ten poradnik jest przeznaczony dla osoby utrzymującej publiczny dokument i sprawdzającej sposób jego dostarczania z poziomu Terminala na Macu. Przykład dotyczy fikcyjnego „Przewodnika po kształtach”, dostępnego pod jednym adresem URL w formacie HTML lub zwykłego tekstu. Zadanie polega na ustaleniu rzeczywistych danych wejściowych wpływających na wybór, skonfigurowaniu odpowiedniego nagłówka odpowiedzi i zweryfikowaniu wyniku.

Co powinno znaleźć się w nagłówku Vary strony?

Vary wymienia pola żądania, które mogą wpływać na wybór reprezentacji, poza metodą żądania i docelowym adresem URL. Jego wartościami są nazwy nagłówków, takie jak Accept, a nie żądane typy mediów. Opisuje sposób wyboru; samo dodanie tego nagłówka go nie implementuje. RFC 9110: Semantyka HTTP, sekcja 12.5.5.

Na przykład jeśli serwer wybiera HTML lub zwykły tekst na podstawie Accept, odpowiednim polem odpowiedzi jest Vary: Accept. Jeśli warstwa dostarczania wybiera również skompresowaną lub nieskompresowaną odpowiedź na podstawie Accept-Encoding, zachowaj ten wymiar: Vary: Accept, Accept-Encoding. To przykłady warunkowe, a nie uniwersalna konfiguracja dla każdej strony. Negocjowanie zawartości.

Praktyczne pytanie brzmi: czy odpowiedź z pamięci podręcznej wybrana dla jednego żądania może być nieodpowiednia dla innego, ponieważ ten nagłówek się zmienił? Buforowanie HTTP wymaga zgodności wskazanych pól, zanim odpowiedź zostanie ponownie użyta bez ponownej walidacji. Brak wskazanego pola jest zgodny z innym brakiem tego pola, a nie z jego obecnością. RFC 9111: Buforowanie HTTP, sekcja 4.1.

Zacznij od sporządzenia wykazu reguł wyboru. Sprawdź reguły aplikacji dotyczące wyboru dokumentu oraz wszelkie późniejsze przekształcenia odpowiedzi. Zmiana wyniku to przydatna wskazówka, ale brak różnicy między dwoma żądaniami nie dowodzi, że nagłówek jest nieistotny dla wszystkich obsługiwanych wartości.

Przygotuj macierz żądań przed wprowadzeniem zmian

Załóżmy, że zamierzone działanie fikcyjnego Przewodnika po kształtach to zwracanie HTML dla preferencji HTML, zwykłego tekstu dla preferencji zwykłego tekstu oraz HTML, gdy brakuje Accept. Obie wersje zawierają te same neutralne informacje: „Koło, kwadrat, trójkąt”. Są to przykładowe wymagania, a nie obserwacje z opublikowanej witryny.

Test Ustawienie żądania Oczekiwany wynik Co sprawdzić
HTML Accept: text/html Dokument HTML Treść, Content-Type, Vary
Zwykły tekst Accept: text/plain Dokument w formacie zwykłego tekstu Treść, Content-Type, Vary
Domyślny Brak pola Accept Dokument HTML Domyślny wybór i Vary
Powtórzenie HTML po zwykłym tekście Ponownie dokument HTML Czy wcześniejszy wariant wpływa na dostarczanie
Nieużywane dane wejściowe Zmień nagłówek nieobecny w regułach wyboru Ta sama wybrana reprezentacja Czy ten nagłówek wymaga zbadania

Podczas pierwszego porównania utrzymuj kompresję bez zmian. W przeciwnym razie różnica w bajtach może wynikać z kompresji, a nie z innego dokumentu. Najpierw zbadaj wybór formatu, a potem osobno kompresję. To rozróżnienie wynika z odrębnych ról Accept i Accept-Encoding. Negocjowanie zawartości.

Zapisuj istotne różnice zamiast polegać wyłącznie na rozmiarze pliku. W tym przykładzie odpowiedź w zwykłym tekście powinna zawierać nazwy kształtów bez znaczników HTML, a jej typ mediów powinien wskazywać zwykły tekst. Zmieniający się znacznik czasu wygenerowania wymagałby zbadania, zanim każdą różnicę bajtową uzna się za nowy wariant.

Ta macierz jest narzędziem diagnostycznym, a nie kompletnym zestawem testów negocjowania zawartości. Gdy podstawowe przypadki działają, dodaj rzeczywiste kombinacje preferencji i wartości jakości obsługiwane przez stronę. Proste żądanie pojedynczego typu nie sprawdza wszystkich gałęzi algorytmu wyboru.

Zapisz porównywalne odpowiedzi w Terminalu na Macu

Potrzebujesz publicznego dokumentu testowego zawierającego fikcyjne materiały, jego końcowego adresu HTTPS oraz Maca z dostępnymi narzędziami bash i curl. Przykład zakłada, że dokument testowy już obsługuje opisane wyżej działanie HTML/zwykły tekst. Nie tworzy, nie przesyła ani nie publikuje tego dokumentu.

Otwórz Terminal i wklej cały poniższy blok. Po wyświetleniu monitu podaj adres URL fikcyjnego dokumentu. Skrypt tworzy nowy tymczasowy katalog raportu i zapisuje treść każdej odpowiedzi obok jej nagłówków; nie nadpisuje wcześniejszego raportu.

bash <<'BASH'
set -eu

printf 'Public synthetic page URL: ' > /dev/tty
IFS= read -r page_url < /dev/tty

case "$page_url" in
  https://*) ;;
  *) printf 'Enter an HTTPS URL.\n' >&2; exit 1 ;;
esac

report_dir=$(mktemp -d "${TMPDIR:-/tmp}/vary-check.XXXXXX")
printf 'Report directory: %s\n' "$report_dir"

for sample in html plain absent html-again; do
  case "$sample" in
    html|html-again) accept_header='Accept: text/html' ;;
    plain) accept_header='Accept: text/plain' ;;
    absent) accept_header='Accept:' ;;
  esac

  curl --disable --silent --show-error --fail \
    --connect-timeout 5 --max-time 20 \
    --header "$accept_header" \
    --header 'Accept-Encoding: identity' \
    --dump-header "$report_dir/$sample.headers" \
    --output "$report_dir/$sample.body" \
    --url "$page_url"
done

printf 'Finished. Responses saved in: %s\n' "$report_dir"
BASH

Opcja --header ustawia kontrolowane pole żądania, a Accept: usuwa generowane wewnętrznie przez curl pole Accept. --dump-header i --output zapisują osobno nagłówki i treści. Limity czasu połączenia i transferu ograniczają czas każdego żądania. Te opcje opisano w podręczniku curl.

Skrypt zatrzymuje się, gdy curl zgłosi błąd transferu lub błąd HTTP objęty opcją --fail. Przed ponowną próbą sprawdź wskazany katalog: wcześniejsze zrzuty mogą nadal się tam znajdować, a nieudany transfer może pozostawić niekompletne pliki. Skrypt celowo nie podąża za przekierowaniami, więc sprawdź wiersz statusu w każdym pliku nagłówków. Jeśli zapisano przekierowanie, użyj końcowego adresu URL dokumentu i rozpocznij nowy raport. Podręcznik curl.

Otwórz w Finderze katalog raportu, korzystając ze ścieżki wyświetlonej przez skrypt. Sprawdź pliki w edytorze zwykłego tekstu. Porównaj html.body z plain.body, a następnie html.body z html-again.body. absent.headers sprawdź równie dokładnie jak odpowiedzi na żądania z jawną preferencją.

Traktuj zapisane wyniki jako obserwacje z tej sekwencji żądań. Nie dowodzą one, że współdzielona pamięć podręczna cokolwiek zapisała. Jeśli chcesz sprawdzić ponowne użycie z pamięci podręcznej, powtórz sekwencję przez docelową ścieżkę dostarczania w udokumentowanych warunkach buforowania, a następnie odwróć kolejność, aby najpierw zażądać zwykłego tekstu.

Zastosuj wynik w warstwie generującej odpowiedź

W przypadku przykładowego Przewodnika po kształtach wyniki dotyczące wyboru formatu powinny wskazywać Accept jako pole wpływające na wybór. Skonfiguruj je w miejscu, w którym generowana lub finalizowana jest odpowiedź HTTP. Jeśli inna warstwa dodaje już niezbędny element Vary, zachowaj go przy dodawaniu elementu dotyczącego wyboru formatu. Końcowa lista powinna opisywać łączne działanie mechanizmu wyboru. RFC 9110: Semantyka HTTP.

Poniższy fragment pokazuje nagłówki odpowiedzi dla przykładu, w którym aktywne są negocjowanie formatu i kompresji. Nie jest to kompletna odpowiedź HTTP ani plik konfiguracyjny serwera.

Vary: Accept, Accept-Encoding

Stosuj tę samą zamierzoną listę Vary dla negocjowanych wariantów i odpowiedzi domyślnej oraz zachowuj ją w odpowiednich odpowiedziach 304 Not Modified. MDN wyraźnie opisuje ten wymóg spójności. Uwzględnij te ścieżki odpowiedzi w weryfikacji, zamiast sprawdzać wyłącznie pierwszą pomyślną odpowiedź HTML. Nagłówek Vary.

Dodanie elementu meta z http-equiv="Vary" nie jest obsługiwanym zamiennikiem. WHATWG definiuje konkretny zestaw dyrektyw pragma HTML, który nie obejmuje Vary, i wyjaśnia, że dyrektywy te w dużej mierze są odrębne od nagłówków HTTP. Skonfiguruj właściwy nagłówek odpowiedzi. Standard HTML: Dyrektywy pragma.

Jeśli interfejs publikowania nie pozwala ustawiać nagłówków odpowiedzi, sprawdź, czy hosting lub warstwa aplikacji oferują udokumentowaną obsługę tej funkcji. Jeśli nie, praktycznym rozwiązaniem dla tego fikcyjnego przykładu jest udostępnienie dokumentów HTML i zwykłego tekstu pod osobnymi adresami URL zapewniającymi stabilne reprezentacje, zamiast negocjowania ich formatów pod jednym adresem. Eliminuje to ten konkretny wymiar wyboru; pozostałe przekształcenia nadal wymagają osobnej oceny.

Diagnozuj brakującą, nadmierną i mylącą zmienność

Na podstawie zapisanych odpowiedzi wybierz następny obszar do zbadania. Poniższa pomoc decyzyjna dotyczy zachowania określonego dla przykładu i nie opisuje żadnej konkretnej usługi hostingowej.

Obserwacja Co zbadać dalej
Żądania HTML i zwykłego tekstu zwracają różne formaty, ale Vary pomija Accept Sprawdź miejsce składania końcowego nagłówka odpowiedzi
Odpowiedzi na jawne warianty zawierają Accept, ale odpowiedź domyślna go pomija Sprawdź ścieżkę odpowiedzi awaryjnej
Powtórne żądanie HTML zwraca wersję w zwykłym tekście Porównaj wybór u źródła z dostarczaniem przez pamięć podręczną
Każde żądanie zwraca ten sam dokument HTML Sprawdź, czy negocjowanie formatu w ogóle istnieje, zanim dodasz element związany z formatem
W Vary pojawia się niepowiązany nagłówek Przed jego usunięciem znajdź regułę wyboru, która go wymaga
Zmiana rozmiaru okna przeglądarki zmienia układ bez zmiany dostarczonego HTML Sprawdź, czy chodzi o prezentację responsywną, a nie wybór po stronie serwera

Brakujący nagłówek w odpowiedzi domyślnej zasługuje na szczególną uwagę: RFC 9111 opisuje, jak pominięcie Vary w odpowiedzi domyślnej może spowodować wybranie tej odpowiedzi dla późniejszych żądań mimo dostępnych alternatyw. Popraw ścieżkę domyślną wraz z jawnymi wariantami. RFC 9111: Buforowanie HTTP.

Nie używaj Vary: * jako skrótu dla niedokończonego wykazu. Zgodnie z zasadami buforowania HTTP zapisana odpowiedź zawierająca ten element zawsze nie przechodzi testu zgodności. Nie wskazuje on, które pola żądania wpływają na wybór dokumentu. RFC 9111: Buforowanie HTTP.

Sprawdzenie w przeglądarce nadal jest przydatne po porównaniu w Terminalu. Standard Fetch WHATWG wyraźnie uwzględnia Vary przy wyborze odpowiedzi z pamięci podręcznej HTTP. Sprawdź dokument zarówno przez zwykłą ścieżkę ładowania w przeglądarce, jak i przez kontrolowane żądania curl. Standard Fetch: pobieranie przez HTTP lub pamięć podręczną.

Zapewnij zgodność sposobu dostarczania strony z wymaganiami Google Search

W przypadku stron zależnych od urządzenia rozróżnij projektowanie responsywne od dynamicznego serwowania. Google opisuje projektowanie responsywne jako dostarczanie tego samego HTML pod tym samym adresem URL na różnych urządzeniach, natomiast dynamiczne serwowanie wybiera inny HTML na podstawie User-Agent i wymaga Vary: User-Agent. Google zaleca projektowanie responsywne ze względu na łatwiejsze wdrażanie i utrzymanie. Najlepsze praktyki dotyczące witryn mobilnych i indeksowania z myślą o urządzeniach mobilnych.

Dlatego fikcyjny Przewodnik po kształtach, który jedynie zmienia układ tego samego HTML za pomocą CSS, nie wymaga dodania User-Agent do Vary tylko z powodu tej zmiany układu. Jeśli serwer rzeczywiście wybiera inny HTML zależnie od urządzenia, dodaj te przypadki do macierzy żądań. Google zaleca również, by główna treść wersji na komputer i urządzenia mobilne była równoważna. Najlepsze praktyki dotyczące witryn mobilnych i indeksowania z myślą o urządzeniach mobilnych.

Zakończ krótką, łatwą do sprawdzenia dokumentacją dostarczania: regułami wyboru dokumentu, macierzą żądań, zapisanymi odpowiedziami i wynikową listą Vary. Każdy wymieniony nagłówek powinien pełnić określoną funkcję, każdy obsługiwany wariant powinien pozostać rozróżnialny, a odpowiedź domyślna powinna spełniać ten sam kontrakt dostarczania.

Źródła