Ange de namn på begäranderubriker i Vary som servern använder för att välja en offentlig sidas representation. Testa en rubrik i taget på en Mac, jämför det returnerade dokumentet och metadata och kontrollera standardsvaret innan du ändrar konfigurationen.

Den här guiden riktar sig till dig som underhåller ett offentligt dokument och kontrollerar hur det levereras från Mac Terminal. Exemplet använder en syntetisk ”Shape Guide” som finns som HTML eller vanlig text på en och samma URL. Uppgiften är att identifiera vilka indata som faktiskt styr urvalet, konfigurera motsvarande svarsrubrik och verifiera resultatet.

Vad hör hemma i en sidas Vary-rubrik?

Vary anger begärandefält som kan påverka valet av representation utöver begärandemetoden och mål-URL:en. Värdena är rubriknamn, till exempel Accept, inte de begärda medietyperna. Rubriken beskriver urvalsbeteendet; att lägga till den implementerar inte beteendet. RFC 9110: HTTP Semantics, avsnitt 12.5.5.

Om servern till exempel väljer HTML eller vanlig text med hjälp av Accept är det relevanta svarsfältet Vary: Accept. Om ett leveranslager också väljer komprimerad eller okomprimerad utdata med hjälp av Accept-Encoding, ska även den dimensionen finnas med: Vary: Accept, Accept-Encoding. Det här är villkorade exempel, inte en universell konfiguration för alla sidor. Innehållsförhandling.

Den praktiska frågan är: kan ett cachat svar som valts för en begäran vara olämpligt för en annan för att den här rubriken har ändrats? HTTP-cachelagring kräver att de angivna fälten matchar innan svaret återanvänds utan omvalidering. Om ett angivet fält saknas matchar det ett annat saknat fält, inte ett fält som finns. RFC 9111: HTTP Caching, avsnitt 4.1.

Börja med att skriva en lista över urvalskriterierna. Kontrollera programmets regler för dokumentval och eventuella svarstransformeringar som tillämpas efteråt. Ett ändrat resultat är användbar evidens, men ett oförändrat resultat från två begäranden visar inte att en rubrik saknar betydelse för alla värden som stöds.

Skapa en begärandematris innan du redigerar något

Anta att den avsedda funktionen för den syntetiska Shape Guide är HTML vid en HTML-preferens, vanlig text vid en preferens för vanlig text och HTML när Accept saknas. Båda versionerna innehåller samma neutrala information: ”Cirkel, kvadrat, triangel.” Det här är illustrativa krav, inte observationer från en publicerad webbplats.

Test Begärandeinställning Avsett resultat Vad du ska granska
HTML Accept: text/html HTML-dokument Innehåll, Content-Type, Vary
Vanlig text Accept: text/plain Dokument med vanlig text Innehåll, Content-Type, Vary
Standard Inget Accept-fält HTML-dokument Standardval och Vary
Upprepning HTML efter vanlig text HTML-dokument igen Om den tidigare varianten påverkar leveransen
Oanvänd indata Ändra en rubrik som saknas i urvalsreglerna Samma valda representation Om rubriken behöver undersökas

Lås komprimeringen under den första jämförelsen. Annars kan en skillnad i byteantal bero på komprimering i stället för ett annat dokument. Undersök först formatvalet och därefter komprimeringen separat. Skillnaden följer av de separata rollerna för Accept och Accept-Encoding. Innehållsförhandling.

Anteckna meningsfulla skillnader i stället för att bara förlita dig på filstorleken. I det här exemplet ska svaret med vanlig text innehålla formnamnen utan HTML-markup, och dess medietyp ska ange vanlig text. Om en genererad tidsstämpel ändras behöver det undersökas innan varje byteförändring behandlas som en ny variant.

Den här matrisen är ett diagnostiskt hjälpmedel, inte en fullständig testsvit för förhandling. När grundfallen fungerar lägger du till de faktiska blandade preferenserna och kvalitetsvärdena som sidan stöder. En enkel begäran med en enda typ testar inte alla grenar i en urvalsalgoritm.

Fånga jämförbara svar i Mac Terminal

Du behöver ett offentligt testdokument med syntetiskt innehåll, dess slutliga HTTPS-URL och en Mac med bash och curl tillgängliga. Exemplet förutsätter att testdokumentet redan stöder beteendet med HTML och vanlig text som beskrivs ovan. Det skapar, laddar inte upp och publicerar inte dokumentet.

Öppna Terminal och klistra in hela blocket nedan. Ange URL:en till ditt syntetiska dokument när du blir ombedd. Skriptet skapar en ny tillfällig rapportkatalog och sparar innehållet i varje svar bredvid dess rubriker. Det skriver inte över en tidigare rapport.

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

Här anger --header den kontrollerade begäranderubriken, och Accept: tar bort curl:s internt genererade Accept-fält. --dump-header och --output sparar rubriker och innehåll separat. Tidsgränserna för anslutning och överföring begränsar varje begäran. Alternativen dokumenteras i curl-manualen.

Skriptet avbryts när curl rapporterar ett överföringsfel eller ett HTTP-fel som omfattas av --fail. Granska den rapporterade katalogen innan du försöker igen: tidigare insamlingar kan finnas kvar och en misslyckad överföring kan lämna ofullständiga filer. Skriptet följer avsiktligt inte omdirigeringar, så kontrollera statusraden i varje rubrikfil. Om du fångade en omdirigering använder du den slutliga dokument-URL:en och skapar en ny rapport. curl-manualen.

Öppna rapportkatalogen i Finder med sökvägen som skriptet skriver ut. Granska filerna i en textredigerare. Jämför html.body med plain.body och jämför sedan html.body med html-again.body. Granska absent.headers lika noggrant som svaren på uttryckliga preferenser.

Behandla de sparade resultaten som observationer från den här begärandesekvensen. De bevisar inte att en delad cache lagrade något. Om du behöver testa återanvändning från cache upprepar du sekvensen via den avsedda leveransvägen under dess dokumenterade cachelagringsvillkor och vänder också på ordningen så att vanlig text kommer först.

Tillämpa resultatet i lagret som skapar svaret

För den illustrativa Shape Guide bör evidensen för formatval stödja att Accept är ett urvalsfält. Konfigurera det där HTTP-svaret skapas eller slutbehandlas. Om ett annat lager redan lägger till en nödvändig Vary-medlem ska du bevara den när du lägger till medlemmen för formatval. Den färdiga listan ska beskriva det samlade urvalsbeteendet. RFC 9110: HTTP Semantics.

Följande är ett utdrag med svarsrubriker för exemplet när både formatval och komprimeringsförhandling är aktiva. Det är inte ett fullständigt HTTP-svar eller en serverkonfigurationsfil.

Vary: Accept, Accept-Encoding

Använd samma avsedda Vary-lista för de förhandlade varianterna och standardsvaret, och bevara den i tillämpliga 304 Not Modified-svar. MDN dokumenterar uttryckligen det här konsekvenskravet. Ta med dessa svarsvägar i verifieringen i stället för att bara kontrollera det första lyckade HTML-svaret. Vary-rubrik.

Att lägga till ett meta-element med http-equiv="Vary" är ingen stödd ersättning. WHATWG definierar en särskild uppsättning pragma-direktiv för HTML, som inte omfattar Vary, och förklarar att dessa direktiv till stor del är åtskilda från HTTP-rubriker. Använd faktisk konfiguration av svarsrubriker. HTML Standard: Pragma directives.

Om publiceringsgränssnittet inte kan ange svarsrubriker kontrollerar du om värd- eller programlagret erbjuder dokumenterat stöd. Om det saknas är ett praktiskt alternativ för det här syntetiska exemplet att ge HTML- och textdokumenten separata URL:er med stabila representationer i stället för att förhandla om deras format på en enda URL. Då försvinner just den urvalsdimensionen; andra transformeringar behöver fortfarande bedömas separat.

Diagnostisera saknad, överdriven och missvisande variation

Använd insamlingarna för att välja nästa undersökning. Följande beslutsstöd gäller det beteende som anges för exemplet; det gör inget påstående om någon viss värdtjänst.

Observation Nästa undersökning
HTML- och textbegäranden ger olika format, men Vary saknar Accept Undersök var den slutliga svarsrubriken sätts samman
Uttryckliga varianter innehåller Accept, men standardsvaret saknar det Undersök reservsvarsvägen
Den upprepade HTML-begäran får textversionen Jämför urvalet vid ursprunget med leveransen via cachen
Varje begäran ger samma HTML-dokument Kontrollera om formatförhandling sker innan du lägger till en formatrelaterad medlem
En orelaterad rubrik visas i Vary Ta reda på vilken urvalsregel som kräver den innan du tar bort den
En storleksändring i webbläsaren ändrar layouten utan att den levererade HTML-koden ändras Kontrollera om detta är responsiv visning snarare än serverbaserat urval

Fallet där standarden saknas förtjänar särskild uppmärksamhet: RFC 9111 beskriver hur utelämnad Vary i ett standardsvar kan leda till att det svaret väljs för senare begäranden trots att alternativ finns. Korrigera standardsvarsvägen tillsammans med de uttryckliga varianterna. RFC 9111: HTTP Caching.

Undvik att använda Vary: * som genväg för en ofärdig lista. Enligt reglerna för HTTP-cachelagring misslyckas alltid matchningstestet för ett lagrat svar som innehåller den medlemmen. Den anger inte vilka begärandefält som styr valet av dokument. RFC 9111: HTTP Caching.

En kontroll i webbläsaren är fortfarande användbar efter jämförelsen i Terminal. WHATWG:s Fetch Standard tar uttryckligen hänsyn till Vary när ett svar från HTTP-cachen väljs. Kontrollera dokumentet både genom den vanliga inläsningsvägen i webbläsaren och via kontrollerade curl-begäranden. Fetch Standard: HTTP-network-or-cache fetch.

Se till att sidleveransen uppfyller Googles Search-krav

För enhetsberoende sidor ska du skilja mellan responsiv design och dynamisk leverans. Google beskriver responsiv design som att samma HTML levereras på samma URL till olika enheter, medan dynamisk leverans väljer olika HTML med User-Agent och använder Vary: User-Agent. Google rekommenderar responsiv design eftersom den är enklare att implementera och underhålla. Bästa praxis för mobilwebbplatser och mobil först-indexering.

Därför finns det ingen anledning för en syntetisk Shape Guide som bara ändrar layouten på samma HTML med CSS att variera på User-Agent enbart på grund av layoutändringen. Om servern faktiskt väljer olika HTML beroende på enhet lägger du till de enhetsfallen i begärandematrisen. Google rekommenderar också att det primära innehållet är likvärdigt mellan dator- och mobilversionerna. Bästa praxis för mobilwebbplatser och mobil först-indexering.

Avsluta med en liten, lättgranskad leveransrapport: reglerna för dokumentval, begärandematrisen, de insamlade svaren och den resulterande Vary-listan. Varje angiven rubrik ska ha en identifierbar roll, varje variant som stöds ska förbli urskiljbar och standardsvaret ska följa samma leveransavtal.

Källor