Last-Modified — lényege, mechanizmusa és a módosítás dátuma fejléc beállítása

Mi az a Last-Modified?

Last-Modified — egy HTTP fejléc, amely a feltételes kérések (conditional requests) fejléccsoportjába tartozik. A szerver hozzáadja a GET vagy HEAD válaszhoz, jelezve a kért erőforrás utolsó módosításának dátumát és időpontját HTTP-date formátumban: Last-Modified: Wed, 02 Jul 2025 14:30:00 GMT. Az üfél (böngésző, mobilalkalmazás, proxy) ezt a dátumot a gyorsítótárazott erőforrással együtt tárolja. Ismételt kérésnél az üfél elküldi az If-Modified-Since fejlécet ugyanazzal a dátummal, és a szerver összehasonlítja azt az erőforrás aktuális módosítási idejével.

A Last-Modified-dzsel történő feltételes kérések protokollját az RFC 7232 határozza meg, és minden modern HTTP szerver támogatja. A dátumformátum szigorúan szabályozott — csak GMT (Greenwich Mean Time) időzóna megjelölése nélkül. A szerver három lehetséges formátumban küldheti vissza a dátumot: RFC 1123 (szabvány), RFC 850 (elavult) vagy ANSI C asctime. A gyakorlatban szinte minden szerver a 29 karakter fix hosszúságú RFC 1123 formátumot használja.

A Last-Modified a gyorsítótár érvényesítő mechanizmusainak kategóriájába tartozik: nem mondja meg az üfélnek, hogy lehet-e gyorsítótárazni a választ, hanem eszközt biztosít a már gyorsítótárazott erőforrás aktualitásának ellenőrzésére. A gyorsítótárazási irányelvet külön a Cache-Control fejlécen keresztül kell beállítani. A Akamai (2025) kutatása szerint a Last-Modified helyes beállítása a Cache-Control-lal együtt akár 70%-kal is csökkentheti a kiszolgáló szerverek terhelését statikus tartalom esetében.

Mikor jelent meg a Last-Modified

A Last-Modified fejlécet már a HTTP/1.0-ban (RFC 1945, 1996) definiálták, és az egyik első gyorsítótár-kezelő mechanizmus volt a weben. Az ETag HTTP/1.1-ben történő megjelenése előtt ez volt az egyetlen mód feltételes kérések végrehajtására. Kora ellenére a fejléc egyszerűségének köszönhetően továbbra is releváns — a szervernek nem kell kiszámítania a tartalom hash-ét, elég a fájl időbélyegét kiolvasni a fájlrendszerből vagy az updated_at mezőt az adatbázisból.

Hogyan működik a Last-Modified?

A teljes ciklus három szakaszból áll. Az első kérésnél a szerver visszaküldi az erőforrást a Last-Modified fejléccel és a 200 OK HTTP állapottal. Az üfél gyorsítótárazza a választ a dátummal együtt. Ismételt kérésnél az üfél elküldi az If-Modified-Since fejlécet a tárolt dátummal. A szerver összehasonlítja ezt a dátumot az erőforrás aktuális módosítási idejével. Ha az erőforrás nem változott — 304 Not Modified válasz kerül visszaküldésre üres törzssel. Ha változott — 200 OK új adatokkal és új Last-Modified-dzsel.

// Első kérés — a szerver visszaküldi az erőforrást a dátummal
HTTP/1.1 200 OK
Content-Type: application/json
Last-Modified: Wed, 02 Jul 2025 14:30:00 GMT

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

// Ismételt kérés — az üfél elküldi a tárolt dátumot
GET /api/users HTTP/1.1
Host: example.com
If-Modified-Since: Wed, 02 Jul 2025 14:30:00 GMT

// Válasz — az adatok nem változtak
HTTP/1.1 304 Not Modified

Mobilalkalmazások számára a Last-Modified különösen hasznos az adatszinkronizáláskor. Az alkalmazás tárolja az utolsó sikeres frissítés dátumát, és elküldi a szervernek az If-Modified-Since-ben. Ha több adat van, vagy azok megváltoztak — a szerver visszaküldi a teljes készletet. Ha nem — 304, és az alkalmazás a helyi másolatot használja. Az OkHttp és az URLSession automatikusan támogatja ezt a mechanizmust a beépített gyorsítótárazó rendszereken keresztül.

Hogyan határozza meg a szerver a dátumot

Statikus fájlok esetében az Nginx és az Apache a dátumot a fájlrendszer attribútumabból veszi — mtime (módosítás ideje). Dinamikus tartalom esetében a szerverkódnak explicit módon kell beállítania a Last-Modified-et üzleti logika alapján: az adatbázis updated_at mezője, az utolsó commit dátuma Git-ben, az építési időbélyeg. Ha a Last-Modified nincs explicit beállítva, a szerver előfordulhat, hogy egyáltalán nem küldi vissza a fejlécet, és az üfél nem tud feltételes kéréseket végrehajtani dátum alapján.

Last-Modified vs ETag

A Last-Modified és az ETag hasonló feladatot lát el — lehetővé teszi az üfél számára a gyorsítótár aktualitásának ellenőrzését — de alapvető különbségekkel rendelkeznek. A Last-Modified időbélyeget használ, az ETag — egyedi verzióazonosítót. Mindkét megközelítésnek megvannak a maga forgatókönyvei, ahol hatékonyabb, és a HTTP specifikáció ajánlása szerint mindkét fejlécet együtt kell használni.

A Last-Modified fő előnye az egyszerűség. A szervernek nem kell kiszámítania a tartalom hash-ét, ami CPU-erőforrásokat spórol minden kérésnél. A nagy terhelésű projektek számára, amelyek statikus fájlokat vagy egyértelmű időbélyegekkel rendelkező adatokat szolgáltatnak, a Last-Modified továbbra is az optimális választás. Az ETag viszont abszolút pontosságot biztosít — egyetlen betű megváltoztatása a JSON válaszban megváltoztatja az ETag-et, de előfordulhat, hogy nem változtatja meg a dátumot (ha a fájlt ugyanazzal a verzióval írták felül).

Közös használat

A specifikáció azt ajánlja, hogy mindkét fejlécet egyszerre küldjük vissza. A szerver mind a Last-Modified-et, mind az ETag-et tartalmazza a 200 OK válaszban. Az üfél mindkét feltételes fejlécet — If-Modified-Since és If-None-Match — elküldi. A szerver először az ETag-et ellenőrzi (elsőbbsége van), majd a Last-Modified-et. Ha legalább az egyik változást jelez — a teljes válasz kerül visszaküldésre. Ez maximális rugalmasságot biztosít: az ETag pontosságot nyújt, a Last-Modified pedig tartalék ellenőrzést azoknak az üféleknek, amelyek nem támogatják az ETag-et.

Last-Modified beállítása a szerveren

A Last-Modified beállítása a szerver típusától függ. Nginx és Apache esetén a statikus fájlok automatikusan megkapják a Last-Modified-et az mtime alapján. Dinamikus alkalmazások esetén a fejlécet a szerver kódjában kell beállítani. Nézzük meg a konfigurációt a népszerű platformokon.

// Express.js — Last-Modified beállítása
app.get("/api/users", async (req, res) => {
    const updatedAt = await getLastUpdate()
    const ifModifiedSince = req.get("If-Modified-Since")

    // If-Modified-Since ellenőrzése
    if (ifModifiedSince && new Date(ifModifiedSince)
        >= updatedAt) {
        return res.status(304).end()
    }

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

Az Express.js példában a szerver lekéri az adatok utolsó frissítésének dátumát az adatbázisból, ellenőrzi az If-Modified-Since-et az üféltől, és ha a gyorsítótár aktuális, 304-et küld vissza. Ha az adatok megváltoztak — új Last-Modified-et állít be, és teljes választ küld. toUTCString() konvertálja a dátumot a szükséges HTTP formátumba. Éles környezetben érdemes hozzáadni az updatedAt gyorsítótárazását Redis-ben, hogy elkerüljük az adatbázis lekérdezést minden hozzáféréskor.

Nginx: Last-Modified beállítása

Az Nginx automatikusan beállítja a Last-Modified-et statikus fájlokhoz a fájl utolsó módosításának ideje alapján. A viselkedés letiltása vagy módosítása az etag irányelvvel (ETag letiltása) vagy az ngx_http_headers_module modulon keresztül lehetséges. A backendhez irányuló proxy kérések esetén a Last-Modified változatlanul kerül továbbításra az upstream válaszból. Fontos: ha a backend nem küld vissza Last-Modified-et, az Nginx nem adja hozzá automatikusan a dinamikus válaszokhoz.

Korlátozások és buktatók

A Last-Modified számos ismert korlátozással rendelkezik. A fő korlát a másodperc pontosság. Ha az erőforrás kétszer változott egy másodpercen belül, az üfél kihagyhatja az új verziót. A gyakorlatban ez ritka forgatókönyv, de nagy frekvenciájú frissítések esetén (árfolyam feedek, csevegések) az ETag ajánlott. A második korlátozás a fürtözési probléma: különböző szervereken a fájl másolás vagy telepítés miatt eltérő mtime-mal rendelkezhet, ami a Last-Modified inkonzisztenciájához vezet.

A harmadik korlátozás — az If-Modified-Since másodperc pontosságú feldolgozása a szerver gyakori lekérdezése esetén többlet kérésekhez vezethet. Ha az üfél 500 ms-enként küld If-Modified-Since-et, a szerver minden alkalommal 200 OK-t küld vissza, mert a dátum nem változott, de az erőforrás valójában már frissölt. A megoldás kombinálás az ETag-dzsel: az ETag észleli a változást egy másodpercen belül, míg a Last-Modified tartalékként marad.

A negyedik probléma — a Last-Modified nem különbözteti meg ugyanazon erőforrás különböző verzióit azonos dátummal. Ha egy fájlt visszaállítottak egy biztonsági mentésből, és az mtime megegyezik az eredetivel, az üfél nem veszi észre, hogy a tartalom megváltozott. Az ETag megoldja ezt a problémát: a tartalom hash garantáltan megváltozik minden adatmódosításkor, függetlenül az időbélyegtől. Kritikus adatok esetén mindig használja mindkét fejlécet.

• Másodperc pontosság — nem érzékeli az egy másodpercen belüli változásokat; használjon ETag-et a nagy frekvenciájú frissítésekhez
• Fürtözés — az mtime különböző szervereken eltérhet; szinkronizálja NTP-n keresztül, vagy használjon ETag-et
• Versenyhelyzet (race condition) — ha az erőforrás az If-Modified-Since elküldése után, de a szerver ellenőrzése előtt változik
• Proxy félreértelmezés — egyes proxyk gyorsítótárazás közben megváltoztathatják a Last-Modified-et; a HTTPS megoldja ezt a problémát