HTTP ETag - HTTP ETag

Den ETag eller enhed tag er en del af HTTP , protokollen for World Wide Web . Det er en af ​​flere mekanismer, som HTTP giver til validering af webcache , som gør det muligt for en klient at fremsætte betingede anmodninger. Denne mekanisme gør det muligt for caches at være mere effektive og sparer båndbredde, da en webserver ikke behøver at sende et fuldt svar, hvis indholdet ikke er ændret. ETags kan også bruges til optimistisk samtidighedskontrol til at forhindre samtidige opdateringer af en ressource i at overskrive hinanden.

En ETag er en uigennemsigtig identifikator, der er tildelt af en webserver til en bestemt version af en ressource, der findes på en URL . Hvis ressourcerepræsentationen på denne URL nogensinde ændres, tildeles en ny og anden ETag. Anvendt på denne måde ligner ETags fingeraftryk og kan hurtigt sammenlignes for at afgøre, om to repræsentationer af en ressource er de samme.

ETag generation

Brugen af ​​ETags i HTTP -headeren er valgfri (ikke obligatorisk som med andre felter i HTTP 1.1 -headeren). Den metode, hvormed ETags genereres, er aldrig blevet specificeret i HTTP -specifikationen.

Almindelige metoder til ETag-generation omfatter brug af en kollisionsresistent hash-funktion af ressourceindholdet, en hash af den sidste ændringstidstempel eller endda bare et revisionsnummer .

For at undgå brug af forældede cachedata bør metoder, der bruges til at generere ETags, garantere (så meget som praktisk), at hver ETag er unik. Imidlertid kan en ETag-generationsfunktion vurderes til at være "brugbar", hvis det (matematisk) kan bevises, at kopiering af ETags ville være "acceptabelt sjælden", selvom den kunne eller ville forekomme.

RFC-7232 siger eksplicit, at ETags skal være indholdskodende bevidste, f.eks

ETag: "123-a" – for no Content-Encoding
ETag: "123-b" – for Content-Encoding: gzip

Nogle tidligere kontrolsumfunktioner , der var svagere end CRC32 eller CRC64, vides at have problemer med hashkollision. Således var de ikke gode kandidater til brug i ETag -generation.

Stærk og svag validering

ETag -mekanismen understøtter både stærk validering og svag validering . De kendetegnes ved tilstedeværelsen af ​​et indledende "W/" i ETag -identifikatoren som:

"123456789"   – A strong ETag validator
W/"123456789" – A weak ETag validator

Et stærkt validerende ETag-match indikerer, at indholdet af de to ressourcerepræsentationer er byte-by-byte identisk, og at alle andre enhedsfelter (f.eks. Indholdssprog) også er uændrede. Stærke ETags tillader cachelagring og genmontering af delvise svar, som ved anmodninger om byte-område .

Et svagt validerende ETag -match indikerer kun, at de to repræsentationer er semantisk ækvivalente , hvilket betyder, at de til praktiske formål kan udskiftes, og at cachelagrede kopier kan bruges. Ressourcerepræsentationerne er imidlertid ikke nødvendigvis byte-by-byte identiske, og derfor er svage ETags ikke egnede til byte-range anmodninger. Svage ETags kan være nyttige i tilfælde, hvor stærke ETags er upraktiske for en webserver at generere, f.eks. Med dynamisk genereret indhold .

Typisk brug

Ved typisk brug, når en URL hentes, returnerer webserveren ressourceens aktuelle repræsentation sammen med den tilhørende ETag -værdi, som er placeret i et "ETag" -felt i HTTP -svaroverskrift:

ETag: "686897696a7c876b7e"

Klienten kan derefter beslutte at gemme repræsentationen i cache sammen med dens ETag. Senere, hvis klienten ønsker at hente den samme URL-ressource igen, vil den først afgøre, om den lokalt cachelagrede version af URL'en er udløbet (gennem Cache-Control og Expire-overskrifterne). Hvis webadressen ikke er udløbet, henter den den lokalt cachelagrede ressource. Hvis det konstateres, at webadressen er udløbet (er forældet ), sender klienten en anmodning til serveren, der indeholder dens tidligere gemte kopi af ETag i feltet "Hvis-ingen-match".

If-None-Match: "686897696a7c876b7e"

På denne efterfølgende anmodning kan serveren nu sammenligne klientens ETag med ETag for den aktuelle version af ressourcen. Hvis ETag -værdierne matcher, hvilket betyder, at ressourcen ikke er ændret, sender serveren muligvis et meget kort svar tilbage med en HTTP 304 ikke ændret status. 304 -status fortæller klienten, at dens cachelagrede version stadig er god, og at den skal bruge den.

Men hvis ETag -værdierne ikke matcher, hvilket betyder, at ressourcen sandsynligvis er ændret, returneres et fuldt svar inklusive ressourceindhold, ligesom hvis ETags ikke blev brugt. I dette tilfælde kan klienten beslutte at erstatte sin tidligere cachelagrede version med den nyligt returnerede repræsentation af ressourcen og den nye ETag.

ETag -værdier kan bruges i overvågningssystemerwebsider . Effektiv overvågning af websider hindres af, at de fleste websteder ikke indstiller ETag -overskrifterne til websider. Når en webmonitor ikke har antydninger om, hvorvidt webindhold er blevet ændret, skal alt indhold hentes og analyseres ved hjælp af computerressourcer til både udgiveren og abonnenten.

Fejlagtig ETag -detektion

Et buggy -websted kan til tider undlade at opdatere ETag, efter at dets semantiske ressource er blevet opdateret. Fra og med 2019 er et eksempel på et fremtrædende sådant websted export.arxiv.org . Som følge heraf er det forkert returnerede svar status 304, og klienten kan ikke hente den opdaterede ressource. Sådan registrerer du et sådant buggy -websted:

  • Gem svaret og ETag, forudsat at der er et ETag, og at svaret ikke blev afbrudt.
  • For en efterfølgende anmodning, der ville have inkluderet If-None-Match-overskriften, skal du ikke sende denne header med måske en tilfældig 20% ​​sandsynlighed. Med denne sandsynlighed, hvis svaret returnerer et ændret indhold, men det samme ETag som det, der tidligere blev cachelagret, skal du markere webstedet som buggy og deaktivere ETag -caching for det. Som en påmindelse kan indholdssammenligningen for en stærk ETag være byte-by-byte, hvorimod den for en svag ETag kun ville kontrollere semantisk ækvivalens.

Sporing ved hjælp af ETags

ETags kan bruges til at spore unikke brugere, da HTTP-cookies i stigende grad slettes af fortrolige brugere. I juli 2011 rapporterede Ashkan Soltani og et team af forskere ved UC Berkeley , at en række websteder, herunder Hulu , brugte ETags til sporing. Hulu og KISSmetrics er begge ophørt med at "respontere" pr. 29. juli 2011, da KISSmetrics og over 20 af dets klienter står over for et gruppesøgsmål om brugen af ​​"uopslettelige" sporingscookies, der delvis involverer brug af ETags.

Fordi ETags cachelagres af browseren og returneres med efterfølgende anmodninger om den samme ressource, kan en tracking -server ganske enkelt gentage enhver ETag modtaget fra browseren for at sikre, at en tildelt ETag vedvarer på ubestemt tid (på samme måde som vedvarende cookies ). Yderligere cachinghoveder kan også forbedre bevarelsen af ​​ETag -data.

ETags kan skylles ved at rydde browserens cache (implementeringer varierer).

Referencer

eksterne links