Setzen Sie Vary auf die Namen der Request-Header, die Ihr Server zur Auswahl der Darstellung einer öffentlichen Seite verwendet. Testen Sie auf einem Mac jeweils einen Header, vergleichen Sie das zurückgegebene Dokument und die Metadaten und prüfen Sie die Standardantwort, bevor Sie die Konfiguration ändern.

Dieser Leitfaden richtet sich an Personen, die ein öffentliches Dokument betreuen und dessen Auslieferung über das Mac-Terminal prüfen. Das durchgehende Beispiel ist ein synthetischer „Formenleitfaden“, der unter einer URL als HTML oder Klartext verfügbar ist. Ziel ist es, die tatsächlichen Auswahlparameter zu bestimmen, den entsprechenden Response-Header zu konfigurieren und das Ergebnis zu überprüfen.

Was gehört in den Vary-Header einer Seite?

Vary nennt Request-Felder, die die Auswahl der Darstellung beeinflussen können, zusätzlich zur Request-Methode und Ziel-URL. Als Werte werden Header-Namen angegeben, etwa Accept, nicht die angeforderten Medientypen. Der Header beschreibt das Auswahlverhalten; durch sein Hinzufügen wird dieses Verhalten nicht implementiert. RFC 9110: HTTP-Semantik, Abschnitt 12.5.5.

Wenn der Server beispielsweise anhand von Accept HTML oder Klartext auswählt, lautet das relevante Response-Feld Vary: Accept. Wenn eine Auslieferungsschicht außerdem anhand von Accept-Encoding komprimierte oder unkomprimierte Ausgaben auswählt, muss auch diese Dimension berücksichtigt werden: Vary: Accept, Accept-Encoding. Das sind bedingte Beispiele und keine universelle Konfiguration für jede Seite. Content Negotiation.

Die praktische Frage lautet: Könnte eine für eine Anfrage ausgewählte und zwischengespeicherte Antwort für eine andere Anfrage ungeeignet sein, weil sich dieser Header geändert hat? HTTP-Caching setzt voraus, dass die genannten Felder übereinstimmen, bevor eine Antwort ohne erneute Validierung wiederverwendet werden kann. Ein fehlendes genanntes Feld stimmt mit einem anderen fehlenden Feld überein, nicht aber mit einem vorhandenen. RFC 9111: HTTP-Caching, Abschnitt 4.1.

Erstellen Sie zunächst eine Übersicht der Auswahlregeln. Prüfen Sie die Regeln der Anwendung für die Dokumentauswahl und alle anschließenden Antworttransformationen. Ein verändertes Ergebnis ist ein nützlicher Hinweis. Bleibt das Ergebnis bei zwei Anfragen unverändert, beweist das jedoch nicht, dass ein Header bei allen unterstützten Werten irrelevant ist.

Erstellen Sie vor Änderungen eine Anfrage-Matrix

Nehmen wir für den synthetischen Formenleitfaden an, dass bei einer HTML-Präferenz HTML, bei einer Klartext-Präferenz Klartext und bei fehlendem Accept HTML ausgeliefert werden soll. Beide Versionen enthalten dieselben neutralen Informationen: „Kreis, Quadrat, Dreieck“. Das sind beispielhafte Anforderungen und keine Beobachtungen einer veröffentlichten Website.

Test Anfrageeinstellung Beabsichtigtes Ergebnis Zu prüfen
HTML Accept: text/html HTML-Dokument Body, Content-Type, Vary
Klartext Accept: text/plain Klartextdokument Body, Content-Type, Vary
Standard Kein Accept-Feld HTML-Dokument Standardauswahl und Vary
Wiederholung HTML nach Klartext Erneut HTML-Dokument Ob die vorherige Variante die Auslieferung beeinflusst
Nicht verwendete Eingabe Einen Header ändern, der in den Auswahlregeln nicht vorkommt Dieselbe ausgewählte Darstellung Ob dieser Header untersucht werden muss

Lassen Sie die Komprimierung beim ersten Vergleich unverändert. Andernfalls könnte ein Byte-Unterschied auf die Komprimierung statt auf ein anderes Dokument zurückgehen. Untersuchen Sie zuerst die Formatauswahl und danach separat die Komprimierung. Diese Unterscheidung entspricht den unterschiedlichen Funktionen von Accept und Accept-Encoding. Content Negotiation.

Halten Sie aussagekräftige Unterschiede fest, statt sich nur auf die Dateigröße zu verlassen. In diesem Beispiel sollte die Klartextantwort die Formennamen ohne HTML-Markup enthalten, und ihr Medientyp sollte Klartext angeben. Ein sich ändernder Zeitstempel in der generierten Antwort muss untersucht werden, bevor jeder Byte-Unterschied als neue Variante gilt.

Diese Matrix ist ein Hilfsmittel zur Diagnose und keine vollständige Testsuite für Content Negotiation. Wenn die grundlegenden Fälle funktionieren, ergänzen Sie die tatsächlich unterstützten kombinierten Präferenzen und Qualitätswerte. Eine einfache Anfrage mit nur einem Medientyp deckt nicht alle Zweige eines Auswahlalgorithmus ab.

Vergleichbare Antworten im Mac-Terminal erfassen

Sie benötigen ein öffentliches Testdokument mit synthetischen Inhalten, dessen endgültige HTTPS-URL sowie einen Mac, auf dem bash und curl verfügbar sind. Das Beispiel setzt voraus, dass das Testdokument das oben beschriebene Verhalten für HTML und Klartext bereits unterstützt. Es erstellt, lädt oder veröffentlicht dieses Dokument nicht.

Öffnen Sie Terminal und fügen Sie den vollständigen Block unten ein. Geben Sie bei der Aufforderung die URL Ihres synthetischen Dokuments ein. Das Skript erstellt ein neues temporäres Berichtsverzeichnis und speichert jeden Antwort-Body neben den zugehörigen Headern. Einen früheren Bericht überschreibt es nicht.

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

Hier übergibt --header das kontrollierte Request-Feld, und Accept: entfernt das intern von curl erzeugte Accept-Feld. --dump-header und --output speichern Header und Bodies getrennt. Die Zeitlimits für Verbindung und Übertragung begrenzen jede Anfrage. Diese Optionen sind im curl-Handbuch dokumentiert.

Das Skript wird beendet, wenn curl einen Übertragungsfehler oder einen von --fail erfassten HTTP-Fehler meldet. Prüfen Sie das angegebene Verzeichnis, bevor Sie es erneut versuchen: Frühere Erfassungen können erhalten bleiben, und bei einer fehlgeschlagenen Übertragung können unvollständige Dateien zurückbleiben. Das Skript folgt Weiterleitungen absichtlich nicht. Prüfen Sie daher die Statuszeile in jeder Header-Datei. Wenn Sie eine Weiterleitung erfasst haben, verwenden Sie die endgültige Dokument-URL und starten Sie einen neuen Bericht. curl-Handbuch.

Öffnen Sie das Berichtsverzeichnis im Finder über den vom Skript ausgegebenen Pfad. Prüfen Sie die Dateien in einem Klartexteditor. Vergleichen Sie html.body mit plain.body und anschließend html.body mit html-again.body. Prüfen Sie absent.headers ebenso sorgfältig wie die Antworten auf explizite Präferenzen.

Betrachten Sie die gespeicherten Ergebnisse als Beobachtungen aus dieser Anfragesequenz. Sie beweisen nicht, dass ein gemeinsamer Cache etwas gespeichert hat. Wenn Sie die Wiederverwendung aus dem Cache prüfen müssen, wiederholen Sie die Sequenz über den vorgesehenen Auslieferungspfad und unter dessen dokumentierten Cache-Bedingungen. Kehren Sie außerdem die Reihenfolge um, sodass zuerst Klartext angefordert wird.

Das Ergebnis auf der Ebene anwenden, die die Antwort erzeugt

Für den beispielhaften Formenleitfaden sollten die Belege zur Formatauswahl Accept als Auswahlfeld bestätigen. Konfigurieren Sie es dort, wo die HTTP-Antwort erzeugt oder abschließend angepasst wird. Wenn eine andere Schicht bereits ein erforderliches Vary-Element beiträgt, behalten Sie es beim Hinzufügen des Elements für die Formatauswahl bei. Die fertige Liste sollte das kombinierte Auswahlverhalten beschreiben. RFC 9110: HTTP-Semantik.

Das Folgende ist ein Response-Header-Fragment für das Beispiel, in dem sowohl die Formatauswahl als auch die Aushandlung der Komprimierung aktiv sind. Es ist weder eine vollständige HTTP-Antwort noch eine Serverkonfigurationsdatei.

Vary: Accept, Accept-Encoding

Verwenden Sie dieselbe vorgesehene Vary-Liste für die ausgehandelten Varianten und die Standardantwort und behalten Sie sie auch bei einschlägigen 304 Not Modified-Antworten bei. MDN dokumentiert diese Konsistenzanforderung ausdrücklich. Nehmen Sie diese Antwortpfade in Ihre Überprüfung auf, statt nur die erste erfolgreiche HTML-Antwort zu prüfen. Vary-Header.

Ein meta-Element mit http-equiv="Vary" ist kein unterstützter Ersatz. Der WHATWG-HTML-Standard definiert eine bestimmte Menge von HTML-Pragma-Direktiven, zu denen Vary nicht gehört. Außerdem erklärt er, dass diese Direktiven größtenteils von HTTP-Headern getrennt sind. Konfigurieren Sie den tatsächlichen Response-Header. HTML-Standard: Pragma-Direktiven.

Wenn Ihre Veröffentlichungsoberfläche keine Response-Header setzen kann, prüfen Sie, ob die Hosting- oder Anwendungsschicht dokumentierte Unterstützung bietet. Ist das nicht verfügbar, können Sie für dieses synthetische Beispiel die HTML- und Klartextdokumente unter separaten URLs mit stabilen Darstellungen bereitstellen, statt ihre Formate unter einer URL auszuhandeln. Damit entfällt diese bestimmte Auswahldimension; andere Transformationen müssen weiterhin separat bewertet werden.

Fehlende, übermäßige und irreführende Variationen diagnostizieren

Wählen Sie anhand der Erfassungen die nächste Untersuchung aus. Die folgende Entscheidungshilfe bezieht sich auf das beschriebene Verhalten des Beispiels; sie stellt keine Aussage über einen bestimmten Hosting-Dienst dar.

Beobachtung Nächste Untersuchung
HTML- und Klartextanfragen liefern unterschiedliche Formate, aber Vary enthält kein Accept Prüfen, wo der endgültige Response-Header zusammengestellt wird
Die expliziten Varianten enthalten Accept, die Standardantwort jedoch nicht Den Pfad der Fallback-Antwort untersuchen
Die wiederholte HTML-Anfrage erhält die Klartextversion Die Auswahl am Ursprung mit der Auslieferung über den Cache vergleichen
Jede Anfrage liefert dasselbe HTML-Dokument Prüfen, ob Content Negotiation stattfindet, bevor ein formatbezogenes Element hinzugefügt wird
Ein nicht zugehöriger Header erscheint in Vary Vor dem Entfernen die erforderliche Auswahlregel ermitteln
Eine Browsergrößenänderung verändert das Layout, aber nicht das ausgelieferte HTML Prüfen, ob es sich um eine responsive Darstellung statt um eine serverseitige Auswahl handelt

Dem Fall einer fehlenden Standardantwort gebührt besondere Aufmerksamkeit: RFC 9111 beschreibt, wie ein fehlendes Vary in einer Standardantwort dazu führen kann, dass diese Antwort bei späteren Anfragen trotz verfügbarer Alternativen ausgewählt wird. Korrigieren Sie den Pfad der Standardantwort zusammen mit den expliziten Varianten. RFC 9111: HTTP-Caching.

Verwenden Sie Vary: * nicht als Abkürzung für eine unvollständige Übersicht. Nach den HTTP-Caching-Regeln besteht eine gespeicherte Antwort mit diesem Element den Übereinstimmungstest immer nicht. Der Header gibt nicht an, welche Request-Felder Ihr Dokument auswählen. RFC 9111: HTTP-Caching.

Eine Browserprüfung ist nach dem Vergleich im Terminal weiterhin sinnvoll. Der Fetch-Standard von WHATWG berücksichtigt Vary ausdrücklich bei der Auswahl einer Antwort aus dem HTTP-Cache. Prüfen Sie das Dokument sowohl über den normalen Ladepfad des Browsers als auch über kontrollierte curl-Anfragen. Fetch-Standard: HTTP-network-or-cache fetch.

Seitenauslieferung und Google-Suchanforderungen aufeinander abstimmen

Unterscheiden Sie bei geräteabhängigen Seiten zwischen Responsive Design und dynamischer Auslieferung. Google beschreibt Responsive Design als Auslieferung desselben HTML unter derselben URL auf verschiedenen Geräten. Bei der dynamischen Auslieferung wird mithilfe von User-Agent unterschiedliches HTML ausgewählt; dafür wird Vary: User-Agent verwendet. Google empfiehlt Responsive Design, weil es einfacher umzusetzen und zu warten ist. Best Practices für mobile Websites und Mobile-First-Indexierung.

Ein synthetischer Formenleitfaden, der dasselbe HTML lediglich mit CSS neu anordnet, hat durch diese Layoutänderung allein folglich keinen Grund, nach User-Agent zu variieren. Wenn der Server tatsächlich je nach Gerät unterschiedliches HTML auswählt, ergänzen Sie diese Gerätefälle in der Anfrage-Matrix. Google empfiehlt außerdem, die Hauptinhalte der Desktop- und Mobilversion gleichwertig zu halten. Best Practices für mobile Websites und Mobile-First-Indexierung.

Schließen Sie die Arbeit mit einer kleinen, überprüfbaren Auslieferungsdokumentation ab: den Regeln für die Dokumentauswahl, der Anfrage-Matrix, den erfassten Antworten und der daraus resultierenden Vary-Liste. Jeder aufgeführte Header sollte eine erkennbare Funktion haben, jede unterstützte Variante unterscheidbar bleiben und die Standardantwort demselben Auslieferungsvertrag folgen.

Quellen