Last-Modified — innebörd, mekanism och konfiguration av ändringsdatumrubriken

Vad är Last-Modified?

Last-Modified — är en HTTP-rubrik som tillhör gruppen rubriker för villkorliga begäran (conditional requests). Servern lägger till den i svaret på GET eller HEAD, och anger datum och tid för senaste ändringen av den begärda resursen i HTTP-date-format: Last-Modified: Wed, 02 Jul 2025 14:30:00 GMT. Klienten (webbläsare, mobilapplikation, proxy) sparar detta datum tillsammans med den cachade resursen. Vid en upprepad begäran skickar klienten rubriken If-Modified-Since med samma datum, och servern jämför det med resursens aktuella ändringstid.

Protokollet för villkorliga begäran med Last-Modified definieras i RFC 7232 och stöds av alla moderna HTTP-servrar. Datumformatet är strikt reglerat — endast GMT (Greenwich Mean Time) utan angivelse av tidszon. Servern kan returnera datumet i tre möjliga format: RFC 1123 (standard), RFC 850 (föråldrat) eller ANSI C asctime. I praktiken använder nästan alla servrar RFC 1123-formatet med en fast längd på 29 tecken.

Last-Modified tillhör kategorin valideringsmekanismer för cache: det säger inte till klienten om svaret kan cachas, utan ger ett verktyg för att kontrollera aktualliteten av en redan cachad resurs. Cachningspolicyn anges separat via Cache-Control-rubriken. Enligt forskning från Akamai (2025) minskar korrekt konfiguration av Last-Modified tillsammans med Cache-Control belastningen på originservrar med upp till 70% för statiskt innehåll.

När uppstod Last-Modified

Last-Modified-rubriken definierades redan i HTTP/1.0 (RFC 1945, 1996) och var en av de första mekanismerna för cachehantering på webben. Innan ETag kom i HTTP/1.1 var det det enda sättet att utföra villkorliga begäran. Trots sin ålder förblir rubriken relevant tack vare sin enkelhet — servern behöver inte beräkna en hash av innehållet, det räcker att läsa filens tidsstämpel från filsystemet eller fältet updated_at från databasen.

Hur fungerar Last-Modified?

Den fullständiga cykeln omfattar tre steg. Vid den första begäran returnerar servern resursen med Last-Modified-rubriken och HTTP-status 200 OK. Klienten cachar svaret tillsammans med datumet. Vid en upprepad begäran skickar klienten rubriken If-Modified-Since med det sparade datumet. Servern jämför detta datum med resursens aktuella ändringstid. Om resursen inte har ändrats — returneras 304 Not Modified med tom kropp. Om den har ändrats — 200 OK med nya data och en ny Last-Modified.

// Första begäran — servern returnerar resursen med datum
HTTP/1.1 200 OK
Content-Type: application/json
Last-Modified: Wed, 02 Jul 2025 14:30:00 GMT

[{"id": 1, "name": "Alice"}]

// Upprepad begäran — klienten skickar sparat datum
GET /api/users HTTP/1.1
Host: example.com
If-Modified-Since: Wed, 02 Jul 2025 14:30:00 GMT

// Svar — data har inte ändrats
HTTP/1.1 304 Not Modified

För mobilapplikationer är Last-Modified särskilt användbart vid datasynkronisering. Applikationen sparar datumet för den senaste lyckade uppdateringen och skickar det till servern i If-Modified-Since. Om det finns mer data eller om den har ändrats — returnerar servern den fullständiga uppsättningen. Om inte — 304, och applikationen använder den lokala kopian. OkHttp och URLSession stöder denna mekanism automatiskt genom inbyggda cachesystem.

Hur servern bestämmer datumet

För statiska filer hämtar Nginx och Apache datumet från filsystemattributen — mtime (ändringstid). För dynamiskt innehåll måste serverkoden explicit ange Last-Modified baserat på affärslogik: fältet updated_at från databasen, datumet för den senaste commiten i Git, tidsstämpeln för artefaktbygget. Om Last-Modified inte anges explicit kan servern låta bli att returnera rubriken helt, och klienten kan inte utföra villkorliga begäran baserat på datum.

Last-Modified vs ETag

Last-Modified och ETag utför en liknande uppgift — de gör det möjligt för klienten att kontrollera cachets aktuallitet — men har grundläggande skillnader. Last-Modified använder en tidsstämpel, ETag — en unik versionsidentifierare. Varje tillvägagångssätt har scenarier där det är effektivare, och HTTP-specifikationens rekommendation är att använda båda rubrikerna tillsammans.

Den största fördelen med Last-Modified är enkelhet. Servern behöver inte beräkna en hash av innehållet, vilket sparar CPU-resurser vid varje begäran. För projekt med hög belastning som levererar statiska filer eller data med tydliga tidsstämplar förblir Last-Modified det optimala valet. ETag å andra sidan ger absolut noggrannhet — ändring av en bokstav i ett JSON-svar kommer att ändra ETag, men kan lämna datumet oförändrat (om filen skrevs över med samma version).

Gemensam användning

Specifikationen rekommenderar att båda rubrikerna returneras samtidigt. Servern inkluderar både Last-Modified och ETag i 200 OK-svaret. Klienten skickar båda villkorliga rubrikerna — If-Modified-Since och If-None-Match. Servern kontrollerar först ETag (har prioritet), sedan Last-Modified. Om minst en signalerar en ändring — returneras det fullständiga svaret. Detta ger maximal flexibilitet: ETag säkerställer noggrannhet, Last-Modified ger en reservkontroll för klienter som inte stöder ETag.

Konfigurera Last-Modified på servern

Konfigurationen av Last-Modified beror på servertypen. För Nginx och Apache anges Last-Modified för statiska filer automatiskt baserat på mtime. För dynamiska applikationer måste rubriken anges i serverkoden. Låt oss titta på konfigurationen på populära plattformar.

// Express.js — ställa in Last-Modified
app.get("/api/users", async (req, res) => {
    const updatedAt = await getLastUpdate()
    const ifModifiedSince = req.get("If-Modified-Since")

    // Kontrollera If-Modified-Since
    if (ifModifiedSince && new Date(ifModifiedSince)
        >= updatedAt) {
        return res.status(304).end()
    }

    const users = await getUsers()
    res.set("Last-Modified", updatedAt.toUTCString())
    res.json(users)
})

I Express.js-exemplet hämtar servern datumet för senaste datauppdatering från databasen, kontrollerar If-Modified-Since från klienten och om cachen är aktuell returnerar den 304. Om data har ändrats — anger den en ny Last-Modified och returnerar det fullständiga svaret. toUTCString() konverterar datumet till det krävda HTTP-formatet. I produktionsmiljö är det värt att lägga till cachning av updatedAt i Redis för att undvika en databasfråga vid varje anrop.

Nginx: konfigurera Last-Modified

Nginx anger automatiskt Last-Modified för statiska filer baserat på filens senaste ändringstid. Inaktivering eller ändring av beteendet kan göras med etag-direktivet (inaktivera ETag) eller via modulen ngx_http_headers_module. För proxy-begäran till backend överförs Last-Modified oförändrat från upstream-svaret. Viktigt: om backend inte returnerar Last-Modified, kommer Nginx inte att lägga till den automatiskt för dynamiska svar.

Begränsningar och fallgropar

Last-Modified har flera kända begränsningar. Den främsta är noggrannhet till sekund. Om en resurs ändras två gånger inom en sekund kan klienten missa den nya versionen. I praktiken är detta ett sällsynt scenario, men för högfrekventa uppdateringar (kursflöden, chattar) rekommenderas ETag. Den andra begränsningen är clustringproblemet: på olika servrar kan en fil ha olika mtime på grund av kopiering eller driftsättning, vilket gör Last-Modified inkonsekvent.

Den tredje begränsningen — bearbetning av If-Modified-Since med sekundnoggrannhet kan leda till överflödiga begäran vid frekvent polling av servern. Om klienten skickar If-Modified-Since var 500:e ms returnerar servern varje gång 200 OK, eftersom datumet inte har ändrats, men resursen har faktiskt redan uppdaterats. Lösningen är kombination med ETag: ETag kommer att fånga ändringen inom en sekund, medan Last-Modified förblir som reserv.

Det fjärde problemet — Last-Modified skiljer inte mellan olika versioner av samma resurs med samma datum. Om en fil återställs från en säkerhetskopia och dess mtime matchar originalet, kommer klienten inte att märka att innehållet har ändrats. ETag löser detta problem: innehållshash kommer garanterat att ändras vid varje dataändring, oavsett tidsstämpel. För kritisk data, använd alltid båda rubrikerna.

• Sekundnoggrannhet — upptäcker inte ändringar inom en sekund; använd ETag för högfrekventa uppdateringar
• Clustring — mtime kan skilja sig på olika servrar; synkronisera via NTP eller använd ETag
• Race condition — om resursen ändras efter att If-Modified-Since skickats men före serverkontroll
• Proxy feltolkning — vissa proxyservrar kan ändra Last-Modified vid cachning; HTTPS löser detta problem