ETag: vad det är, cachelagringsmekanism och konfiguration av huvudet

Vad är ETag?

ETag (Entity Tag) — är en HTTP-svarshuvud som innehåller en unik identifierare för en specifik version av en resurs. Servern beräknar ETag baserat på filens innehåll, dess metadata eller revisionsnummer och överför det till klienten i svaret på en GET-begäran. Klienten sparar denna identifierare och vid efterföljande begäran till samma resurs skickar den den i If-None-Match-rubriken. Om resursen inte har ändrats svarar servern med 304 Not Modified, och klienten använder sin cachade kopia.

Formatet för ETag definieras i RFC 7232 som en sträng inom citattecken: "33a64df551425fcc55e4d42a148795d9f25f89d4". Värdet kan vara en SHA-1-hash av filens innehåll, ett inkrementellt versionsnummer, en kombination av inode-nummer-tid för statiska filer eller en godtycklig token som genereras av servern. Det enda kravet är att värdet ändras vid varje ändring av resursen och inte ändras om resursen förblir densamma.

ETag tillhör mekanismerna för villkorliga begäran (conditional requests) — en av grundläggande optimeringar av HTTP-protokollet. Till skillnad från ovillkorliga begäran där servern alltid returnerar ett fullständigt svar, tillåter en villkorlig begäran klienten att kontrollera cachets aktuallitet utan att ladda ner data igen. Enligt data från HTTP Archive (2025) är cirka 40% av alla HTTP-svar 304 Not Modified tack vare korrekt konfiguration av ETag och Last-Modified.

Var tillämpas ETag

ETag används i REST API för att optimera laddning av datainsamlingar — om listan med objekt inte har ändrats får klienten 304 utan att skicka hela JSON. I statiska filer (CSS, JS, bilder) gör ETag det möjligt för CDN:er och webbläsare att effektivt kontrollera cachets aktuallitet. I mobilapplikationer är ETag avgörande för bakgrundssynkronisering: applikationen kontrollerar om data på servern har ändrats och laddar ner uppdateringar endast vid behov. Detta sparar bandbredd och enhetens batteri.

Hur fungerar ETag?

Den fullständiga arbetscykeln för ETag består av fyra steg. Servern genererar ETag vid den första begäran och returnerar den i svarshuvudet. Klienten sparar ETag tillsammans med den cachade resursen. Vid en upprepad begäran skickar klienten If-None-Match-rubriken med värdet av den sparade ETag. Servern jämför det mottagna värdet med resursens aktuella ETag: vid överensstämmelse returneras 304 Not Modified med tom kropp, vid bristande överensstämmelse — 200 OK med en ny resurs och en ny ETag.

// Klientbegäran med If-None-Match
GET /api/users HTTP/1.1
Host: example.com
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

// Serversvar — resursen har inte ändrats
HTTP/1.1 304 Not Modified
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

I en mobilapplikation kan denna cykel implementeras via en HTTP-klient med cache-stöd. OkHttp hanterar till exempel automatiskt ETag via CacheInterceptor: det sparar svarets ETag och lägger vid en upprepad begäran till If-None-Match. Vid mottagande av 304 returnerar OkHttp cachad data. OkHttp stödjer ETag utan ytterligare konfiguration — det räcker att aktivera cachen via OkHttpClient.Builder.cache().

Generering av ETag på servern

Servern kan beräkna ETag på olika sätt: via en MD5- eller SHA-hash av innehållet, via ett revisionsnummer från databasen (till exempel updated_at från MySQL), via en kombination av inode + mtime + size för statiska filer (Nginx genererar ETag precis på detta sätt). För dynamiska API:er är innehållshashen mest tillförlitlig: om JSON-svaret har ändrat även ett fält, kommer ETag att ändras. Att beräkna hash vid varje begäran belastar dock processorn — för system med hög belastning är det bättre att använda ett inkrementellt versionsnummer.

Starka och svaga ETag

RFC 7232 definierar två typer av ETag: starka (strong) och svaga (weak). En stark ETag innebär att två representationer av resursen är identiska byte-för-byte — inte en enda bit skiljer sig. En svag ETag (prefix W/) garanterar endast semantisk likvärdighet: innehållet kan skilja sig på serialiseringsnivå (mellanslag, ordning på JSON-fält), men data anses vara densamma för klienten. Svaga ETag markeras med prefixet W/, till exempel W/"1a2b3c".

Valet av ETag-typ beror på kraven för jämförelsenoggrannhet. För statiska filer (CSS, JS, bilder) föredras starka ETag — om filen har ändrats måste klienten få den nya versionen. För dynamiska API:er, där samma JSON kan serialiseras med olika fältordning eller formatering, ger svaga ETag mer flexibilitet: servern genererar ETag baserat på affärsdata, inte på strängrepresentationen.

Begränsning av svaga ETag: de kan inte användas med intervallbegäran (Range requests). Om klienten begär en del av filen måste servern returnera en stark ETag för att garantera att fragmentet motsvarar den fullständiga resursen. Svaga ETag ger inte en sådan garanti. I andra scenarier är svaga ETag säkra och rekommenderas för API:er.

ETag vs Last-Modified

ETag och Last-Modified är två HTTP-rubriker för villkorliga begäran som ofta används tillsammans. Last-Modified anger datumet för senaste ändringen av resursen och fungerar med If-Modified-Since-rubriken. ETag ger en unik versionsidentifierare och fungerar med If-None-Match. Var och en har sina fördelar och begränsningar, och kombinationen ger maximal cacheeffektivitet.

Last-Modified är enklare att implementera — servern hämtar automatiskt datumet från filsystemet eller uppdaterar fältet updated_at i databasen. Datumet har dock en precision på en sekund, vilket är otillräckligt för resurser som ändras flera gånger per sekund. Dessutom skiljer Last-Modified inte på olika tillstånd: om filen skrivs över med samma version ändras datumet, men innehållet gör det inte — klienten laddar identiska data igen.

ETag är mer exakt: det ändras endast vid en verklig ändring av innehållet. Om servern återställer den tidigare versionen från en säkerhetskopia kommer ETag att ändras. Om filen skrivs över med samma data — förblir ETag densamma, och klienten kommer inte att ladda om. Gemensam användning rekommenderas av HTTP-specifikationen: servern returnerar båda rubrikerna, klienten skickar If-None-Match och If-Modified-Since samtidigt. Om åtminstone en rubrik indikerar en ändring — returnerar servern en ny resurs.

Prioritet för rubriker

Enligt specifikationen har ETag prioritet över Last-Modified. Om servern har tagit emot If-None-Match ska den endast kontrollera ETag, ignorera If-Modified-Since. Detta förhindrar race condition: om resursen har ändrats mellan klientens sändning av Last-Modified och kontrollen på servern kommer ETag att vara en färskare indikator. I praktiken kontrollerar servrar vanligtvis båda rubrikerna, men vid icke-överensstämmande resultat vinner ETag.

Implementering av ETag på servern

Konfigurationen av ETag beror på servertypen. Nginx genererar ETag för statiska filer automatiskt baserat på inode, mtime och storlek. Apache använder FileETag-mekanismen. För dynamiska applikationer i Node.js, PHP, Python, Ruby måste ETag genereras programmatiskt — via en hash av svaret, ett versionsnummer för data eller en kombination av begäranparametrar.

func etagMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter,
        r *http.Request) {
        // Generering av ETag baserat på data
        etag := generateETag(r.URL.Path)
        w.Header().Set("ETag", etag)

        // Kontroll av If-None-Match
        if r.Header.Get("If-None-Match") == etag {
            w.WriteHeader(http.StatusNotModified)
            return
        }
        next.ServeHTTP(w, r)
    })
}

Middleware i Go fångar upp begäran, genererar ETag för den begärda URL:en (till exempel beräknar en hash av data från cache eller databas) och ställer in svarshuvudet. Om klienten har skickat If-None-Match och den matchar den aktuella ETag, returnerar servern omedelbart 304 Not Modified, utan att anropa huvudhanteraren. I produktionsmiljö är det värt att lägga till cachelagring av beräknade ETag efter URL och parametrar för att minska serverbelastningen.

Problem och fallgropar

I en multi-server-konfiguration (round-robin eller anycast) måste ETag vara densamma på alla noder för samma resurs. Om ETag genereras baserat på filens inode och webbplatsen körs på flera servrar kommer värdena att skilja sig. Lösningen — användning av innehållshash eller centraliserad versionslagring (Redis, etcd). Det andra problemet — gzip-komprimering: Nginx ändrar ETag när komprimering är aktiverad, vilket kan orsaka överdrivna 304-svar. Konfigurering av gzip_vary on krävs för synkronisering av ETag med komprimerat innehåll.