Stel Vary in op de namen van de requestheaders die je server gebruikt om de representatie van een openbare pagina te selecteren. Test op een Mac telkens één header, vergelijk het geretourneerde document en de metadata, en controleer de standaardrespons voordat je de configuratie wijzigt.

Deze handleiding is bedoeld voor iemand die een openbaar document beheert en de levering ervan controleert via Terminal op een Mac. Het uitgewerkte voorbeeld is een fictieve “Vormengids” die op één URL beschikbaar is als HTML of platte tekst. De taak is de daadwerkelijke selectie-invoer vast te stellen, de bijbehorende responsheader te configureren en het resultaat te verifiëren.

Wat hoort er in de Vary-header van een pagina?

Vary vermeldt requestvelden die van invloed kunnen zijn op de selectie van een representatie, naast de requestmethode en doel-URL. De waarden zijn headernamen, zoals Accept, en niet de aangevraagde mediatypen. De header beschrijft het selectiegedrag; door hem toe te voegen wordt dat gedrag niet geïmplementeerd. RFC 9110: HTTP Semantics, sectie 12.5.5.

Als de server bijvoorbeeld HTML of platte tekst selecteert op basis van Accept, is het relevante responsveld Vary: Accept. Als een leveringslaag ook gecomprimeerde of niet-gecomprimeerde uitvoer selecteert op basis van Accept-Encoding, behoud dan ook die dimensie: Vary: Accept, Accept-Encoding. Dit zijn voorwaardelijke voorbeelden, geen universele configuratie voor elke pagina. Content negotiation.

De praktische vraag is: kan een gecachte respons die voor de ene request is geselecteerd ongeschikt zijn voor een andere, omdat deze header is gewijzigd? HTTP-caching vereist dat de genoemde velden overeenkomen voordat de respons zonder hervalidatie opnieuw mag worden gebruikt. Een ontbrekend genoemd veld komt overeen met een ander ontbrekend veld, niet met een aanwezig veld. RFC 9111: HTTP Caching, sectie 4.1.

Begin met het opstellen van een selectieoverzicht. Controleer de documentselectieregels van de applicatie en eventuele responsbewerkingen die daarna worden toegepast. Een gewijzigd resultaat is nuttig bewijs, maar het feit dat twee requests hetzelfde resultaat opleveren, bewijst niet dat een header irrelevant is voor alle ondersteunde waarden.

Stel een requestmatrix op voordat je iets wijzigt

Stel voor de fictieve Vormengids dat het beoogde gedrag HTML is bij een HTML-voorkeur, platte tekst bij een voorkeur voor platte tekst, en HTML wanneer Accept ontbreekt. Beide versies bevatten dezelfde neutrale informatie: “Cirkel, vierkant, driehoek.” Dit zijn illustratieve vereisten, geen waarnemingen van een gepubliceerde site.

Test Requestinstelling Beoogd resultaat Wat je controleert
HTML Accept: text/html HTML-document Inhoud, Content-Type, Vary
Platte tekst Accept: text/plain Document met platte tekst Inhoud, Content-Type, Vary
Standaard Geen Accept-veld HTML-document Standaardselectie en Vary
Herhaling HTML na platte tekst Opnieuw HTML-document Of de eerdere variant de levering beïnvloedt
Ongebruikte invoer Wijzig een header die niet in de selectieregels voorkomt Dezelfde geselecteerde representatie Of die header verder onderzoek vereist

Houd compressie tijdens de eerste vergelijking constant. Anders kan een verschil in bytes het gevolg zijn van compressie in plaats van een ander document. Onderzoek eerst de formaatselectie en daarna afzonderlijk de compressie. Dit onderscheid volgt uit de afzonderlijke rollen van Accept en Accept-Encoding. Content negotiation.

Noteer betekenisvolle verschillen in plaats van alleen op bestandsgrootte te vertrouwen. In dit voorbeeld hoort de respons met platte tekst de vormnamen zonder HTML-opmaak te bevatten, en moet het mediatype platte tekst aangeven. Een gegenereerde tijdstempel die verandert, moet je onderzoeken voordat je elk verschil in bytes als een nieuwe variant beschouwt.

Deze matrix is een hulpmiddel voor diagnose, geen volledige testreeks voor content negotiation. Voeg, zodra de basisgevallen werken, de daadwerkelijke combinaties van voorkeuren en kwaliteitswaarden toe die je pagina ondersteunt. Een eenvoudige request met één type doorloopt niet elke tak van een selectiealgoritme.

Vergelijkbare responses vastleggen in Terminal op een Mac

Je hebt een openbaar testdocument met synthetische inhoud nodig, de definitieve HTTPS-URL en een Mac waarop bash en curl beschikbaar zijn. In het voorbeeld wordt ervan uitgegaan dat het testdocument het hierboven beschreven gedrag voor HTML en platte tekst al ondersteunt. Het maakt, uploadt of publiceert dat document niet.

Open Terminal en plak het volledige blok hieronder. Voer desgevraagd de URL van je synthetische document in. Het script maakt een nieuwe tijdelijke map voor het rapport en bewaart de inhoud van elke respons naast de bijbehorende headers; een eerder rapport wordt niet overschreven.

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

--header geeft hier het gecontroleerde requestveld op, en Accept: verwijdert de intern door curl gegenereerde Accept-header. --dump-header en --output slaan headers en inhoud afzonderlijk op. De tijdslimieten voor verbinding en gegevensoverdracht begrenzen elke request. Deze opties worden beschreven in de curl-handleiding.

Het script stopt wanneer curl een overdrachtsfout meldt of een HTTP-fout die onder --fail valt. Controleer de vermelde map voordat je het opnieuw probeert: eerdere vastleggingen kunnen blijven staan en een mislukte overdracht kan onvolledige bestanden achterlaten. Het volgt bewust geen omleidingen, dus controleer de statusregel in elk headerbestand. Als je een omleiding hebt vastgelegd, gebruik dan de URL van het uiteindelijke document en begin een nieuw rapport. curl-handleiding.

Open de rapportmap in Finder met het pad dat het script afdrukt. Bekijk de bestanden in een editor voor platte tekst. Vergelijk html.body met plain.body en vergelijk vervolgens html.body met html-again.body. Bekijk absent.headers even zorgvuldig als de responses met expliciete voorkeuren.

Beschouw de opgeslagen resultaten als waarnemingen van deze requestreeks. Ze bewijzen niet dat een gedeelde cache iets heeft opgeslagen. Als je cachehergebruik wilt testen, herhaal dan de reeks via het beoogde leveringspad onder de gedocumenteerde cachebare omstandigheden en draai de volgorde ook om, zodat platte tekst eerst komt.

Pas het resultaat toe op de laag die de respons produceert

Voor de fictieve Vormengids hoort het bewijs voor formaatselectie Accept als selecterend veld te ondersteunen. Configureer dit op de plek waar de HTTP-respons wordt gegenereerd of definitief wordt samengesteld. Als een andere laag al een noodzakelijke Vary-waarde toevoegt, behoud die dan wanneer je de waarde voor formaatselectie toevoegt. De uiteindelijke lijst moet het gecombineerde selectiegedrag beschrijven. RFC 9110: HTTP Semantics.

Hieronder staat een fragment met responsheaders voor het voorbeeld waarin zowel formaatselectie als compressieonderhandeling actief is. Het is geen volledige HTTP-respons of serverconfiguratiebestand.

Vary: Accept, Accept-Encoding

Gebruik dezelfde beoogde Vary-lijst voor de onderhandelde varianten en de standaardrespons, en behoud die bij toepasselijke 304 Not Modified-responses. MDN documenteert deze consistentievereiste expliciet. Neem deze responspaden mee in je verificatie en controleer niet alleen de eerste geslaagde HTML-respons. Vary-header.

Een element meta toevoegen met http-equiv="Vary" is geen ondersteund alternatief. WHATWG definieert een specifieke reeks pragma-instructies voor HTML, waar Vary niet bij hoort, en legt uit dat deze instructies grotendeels losstaan van HTTP-headers. Configureer de daadwerkelijke responsheader. HTML Standard: Pragma directives.

Als je publicatie-interface geen responsheaders kan instellen, controleer dan of de hosting- of applicatielaag hiervoor gedocumenteerde ondersteuning biedt. Als die ontbreekt, is een praktisch alternatief voor dit synthetische voorbeeld om de HTML- en plattetekstdocumenten afzonderlijke URL’s met stabiele representaties te geven, in plaats van hun formaten op één URL te onderhandelen. Daarmee vervalt die specifieke selectiedimensie; andere transformaties moeten nog steeds afzonderlijk worden beoordeeld.

Ontbrekende, overmatige en misleidende variatie opsporen

Gebruik de vastleggingen om te bepalen wat je vervolgens onderzoekt. De volgende besliswijzer geldt voor het beschreven gedrag van het voorbeeld; het is geen bewering over een specifieke hostingdienst.

Waarneming Volgend onderzoek
HTML- en plattetekstrequests leveren verschillende formaten op, maar Vary bevat geen Accept Controleer waar de uiteindelijke responsheader wordt samengesteld
Expliciete varianten bevatten Accept, maar de standaardrespons niet Controleer het pad voor de fallbackrespons
De herhaalde HTML-request ontvangt de versie met platte tekst Vergelijk de selectie bij de origin met de levering via de cache
Elke request levert hetzelfde HTML-document op Controleer of formaatonderhandeling bestaat voordat je een formaatgerelateerde waarde toevoegt
Een niet-gerelateerde header staat in Vary Zoek de selectieregel die deze vereist voordat je hem verwijdert
Een wijziging van de browsergrootte verandert de indeling zonder de geleverde HTML te wijzigen Controleer of het om responsieve presentatie gaat in plaats van serverselectie

Het ontbrekende geval voor de standaardrespons verdient bijzondere aandacht: RFC 9111 beschrijft hoe het weglaten van Vary bij een standaardrespons ertoe kan leiden dat die respons voor latere requests wordt geselecteerd, ondanks beschikbare alternatieven. Corrigeer het pad voor de standaardrespons tegelijk met de expliciete varianten. RFC 9111: HTTP Caching.

Gebruik Vary: * niet als snelle oplossing voor een onvolledig selectieoverzicht. Volgens de HTTP-cache-regels slaagt een opgeslagen respons met deze waarde nooit voor de matchtest. De waarde geeft niet aan welke requestvelden je document selecteren. RFC 9111: HTTP Caching.

Ook na de vergelijking in Terminal is een browsercontrole nuttig. De Fetch Standard van WHATWG houdt expliciet rekening met Vary bij het selecteren van een respons uit de HTTP-cache. Controleer het document zowel via de normale laadroute van de browser als via gecontroleerde curl-requests. Fetch Standard: HTTP-network-or-cache fetch.

Stem de paginalevering af op de vereisten van Google Search

Maak voor apparaatafhankelijke pagina’s onderscheid tussen responsief ontwerp en dynamische weergave. Google beschrijft responsief ontwerp als het aanbieden van dezelfde HTML op dezelfde URL voor verschillende apparaten, terwijl bij dynamische weergave andere HTML wordt geselecteerd op basis van User-Agent en Vary: User-Agent wordt gebruikt. Google beveelt responsief ontwerp aan omdat het eenvoudiger te implementeren en te onderhouden is. Best practices voor mobiele sites en mobile-first indexering.

Een fictieve Vormengids die dezelfde HTML alleen met CSS anders rangschikt, heeft dus niet alleen vanwege die wijziging in de lay-out reden om op User-Agent te variëren. Als de server daadwerkelijk andere HTML selecteert op basis van het apparaat, voeg dan die apparaatgevallen toe aan de requestmatrix. Google adviseert ook om de belangrijkste inhoud gelijkwaardig te houden tussen desktop- en mobiele versies. Best practices voor mobiele sites en mobile-first indexering.

Sluit af met een beknopt, controleerbaar leveringsverslag: de documentselectieregels, de requestmatrix, de vastgelegde responses en de uiteindelijke Vary-lijst. Elke vermelde header moet een aanwijsbare rol hebben, elke ondersteunde variant moet onderscheidbaar blijven en de standaardrespons moet aan hetzelfde leveringscontract voldoen.

Bronnen