Last-Modified — esensya, mekanismo, at pagsasaayos ng header ng petsa ng pagbabago

Ano ang Last-Modified?

Last-Modified — ay isang HTTP header na kabilang sa grupo ng mga conditional request header. Idinaragdag ito ng server sa tugon sa GET o HEAD, na nagpapahiwatig ng petsa at oras ng huling pagbabago ng hiniling na resource sa format na HTTP-date: Last-Modified: Wed, 02 Jul 2025 14:30:00 GMT. Ang client (browser, mobile application, proxy) ay nag-iimbak ng petsang ito kasama ng naka-cache na resource. Sa paulit-ulit na kahilingan, nagpapadala ang client ng If-Modified-Since header na may parehong petsa, at inihahambing ito ng server sa kasalukuyang oras ng pagbabago ng resource.

Ang protocol ng conditional request na may Last-Modified ay tinukoy sa RFC 7232 at sinusuportahan ng lahat ng modernong HTTP server. Ang format ng petsa ay mahigpit na kinokontrol — tanging GMT (Greenwich Mean Time) nang hindi tinutukoy ang time zone. Maaaring ibalik ng server ang petsa sa tatlong posibleng format: RFC 1123 (standard), RFC 850 (luma na), o ANSI C asctime. Sa praktika, halos lahat ng server ay gumagamit ng RFC 1123 format na may nakapirming haba na 29 character.

Ang Last-Modified ay kabilang sa kategorya ng validation mechanisms ng cache: hindi nito sinasabi sa client kung maaari i-cache ang tugon, ngunit nagbibigay ito ng tool para suriin ang aktuwalidad ng naka-cache na resource. Ang patakaran sa pag-cache ay itinakda nang hiwalay sa pamamagitan ng Cache-Control header. Ayon sa pananaliksik ng Akamai (2025), ang tamang configuration ng Last-Modified kasama ng Cache-Control ay nakakabawas ng load sa origin server ng hanggang 70% para sa static na nilalaman.

Kailan lumitaw ang Last-Modified

Ang Last-Modified header ay tinukoy na noong HTTP/1.0 (RFC 1945, 1996) at isa sa mga unang mekanismo ng pamamahala ng cache sa web. Bago ang paglitaw ng ETag sa HTTP/1.1, ito ang tanging paraan upang magsagawa ng conditional requests. Sa kabila ng edad nito, nananatiling mahalaga ang header dahil sa pagiging simple nito — hindi kailangang kalkulahin ng server ang hash ng nilalaman, sapat na basahin ang timestamp ng file mula sa file system o ang updated_at field mula sa database.

Paano gumagana ang Last-Modified?

Ang buong cycle ay may kasamang tatlong yugto. Sa unang kahilingan, ibinabalik ng server ang resource na may Last-Modified header at HTTP status na 200 OK. Ini-cache ng client ang tugon kasama ng petsa. Sa paulit-ulit na kahilingan, nagpapadala ang client ng If-Modified-Since header kasama ang nakaimbak na petsa. Inihahambing ng server ang petsang ito sa kasalukuyang oras ng pagbabago ng resource. Kung hindi nagbago ang resource — ibinabalik ang 304 Not Modified na walang laman ang body. Kung nagbago — 200 OK na may bagong data at bagong Last-Modified.

// Unang kahilingan — ibinabalik ng server ang resource na may petsa
HTTP/1.1 200 OK
Content-Type: application/json
Last-Modified: Wed, 02 Jul 2025 14:30:00 GMT

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

// Paulit-ulit na kahilingan — nagpapadala ang client ng nakaimbak na petsa
GET /api/users HTTP/1.1
Host: example.com
If-Modified-Since: Wed, 02 Jul 2025 14:30:00 GMT

// Tugon — hindi nagbago ang data
HTTP/1.1 304 Not Modified

Para sa mga mobile application, ang Last-Modified ay lalong kapaki-pakinabang sa pag-sync ng data. Iniimbak ng application ang petsa ng huling matagumpay na pag-update at ipinapadala ito sa server sa If-Modified-Since. Kung may mas maraming data o nagbago na ang mga ito — ibinabalik ng server ang kumpletong set. Kung hindi — 304, at ginagamit ng application ang lokal na kopya. OkHttp at URLSession ay awtomatikong sumusuporta sa mekanismong ito sa pamamagitan ng built-in na caching system.

Paano tinutukoy ng server ang petsa

Para sa mga static na file, kinukuha ng Nginx at Apache ang petsa mula sa mga attribute ng file system — mtime (oras ng pagbabago). Para sa dynamic na nilalaman, ang server code ay dapat na tahasang magtakda ng Last-Modified batay sa business logic: updated_at field mula sa database, petsa ng huling commit sa Git, timestamp ng pagbuo ng artifact. Kung ang Last-Modified ay hindi tahasang itinakda, maaaring hindi ibalik ng server ang header, at hindi magagawa ng client ang conditional requests batay sa petsa.

Last-Modified vs ETag

Ang Last-Modified at ETag ay may katulad na tungkulin — pinapayagan nila ang client na suriin ang aktuwalidad ng cache — ngunit mayroon silang pangunahing pagkakaiba. Gumagamit ang Last-Modified ng time stamp, ang ETag — ng natatanging identifier ng bersyon. Ang bawat approach ay may mga scenario kung saan ito ay mas epektibo, at ang rekomendasyon ng HTTP specification ay gamitin ang parehong header nang magkasama.

Ang pangunahing bentahe ng Last-Modified ay pagiging simple. Hindi kailangang kalkulahin ng server ang hash ng nilalaman, na nakakatipid ng CPU resources sa bawat kahilingan. Para sa mga proyektong may mataas na load na naghahatid ng static na file o data na may malinaw na time stamp, ang Last-Modified ay nananatiling pinakamainam na pagpipilian. Ang ETag naman ay nagbibigay ng ganap na katumpakan — ang pagbabago ng isang letra sa JSON response ay magbabago sa ETag, ngunit maaaring hindi magbago ang petsa (kung ang file ay na-overwrite ng parehong bersyon).

Pinagsamang paggamit

Inirerekomenda ng specification na ibalik ang parehong header nang sabay. Isinasama ng server ang parehong Last-Modified at ETag sa 200 OK response. Nagpapadala ang client ng parehong conditional header — If-Modified-Since at If-None-Match. Sinusuri muna ng server ang ETag (may priyoridad), pagkatapos ang Last-Modified. Kung hindi bababa sa isa ang nagsenyas ng pagbabago — ibinabalik ang kumpletong tugon. Nagbibigay ito ng maximum na flexibility: ang ETag ay nagbibigay ng katumpakan, ang Last-Modified ay nagbibigay ng backup na pagsusuri para sa mga client na hindi sumusuporta sa ETag.

Pagsasaayos ng Last-Modified sa server

Ang configuration ng Last-Modified ay depende sa uri ng server. Para sa Nginx at Apache, ang mga static na file ay awtomatikong binibigyan ng Last-Modified batay sa mtime. Para sa mga dynamic na application, ang header ay dapat itakda sa server code. Tingnan natin ang configuration sa mga sikat na platform.

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

    // Pagsusuri ng 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)
})

Sa halimbawa ng Express.js, kinukuha ng server ang petsa ng huling pag-update ng data mula sa database, sinusuri ang If-Modified-Since mula sa client, at kung ang cache ay napapanahon, nagbabalik ng 304. Kung nagbago ang data — nagtatakda ng bagong Last-Modified at nagbabalik ng kumpletong tugon. toUTCString() nagko-convert ng petsa sa kinakailangang HTTP format. Sa production environment, mainam na magdagdag ng caching ng updatedAt sa Redis upang maiwasan ang database query sa bawat pag-access.

Nginx: configuration ng Last-Modified

Awtomatikong nagtatakda ang Nginx ng Last-Modified para sa mga static na file batay sa oras ng huling pagbabago ng file. Ang pag-disable o pagbabago ng gawi ay maaaring gawin sa pamamagitan ng etag directive (pag-disable ng ETag) o sa pamamagitan ng modyul na ngx_http_headers_module. Para sa proxy requests sa backend, ang Last-Modified ay ipinapasa mula sa upstream response nang walang pagbabago. Mahalaga: kung ang backend ay hindi nagbabalik ng Last-Modified, hindi ito awtomatikong idadagdag ng Nginx para sa mga dynamic na tugon.

Mga limitasyon at patibong

Ang Last-Modified ay may ilang kilalang limitasyon. Ang pangunahin ay katumpakan hanggang segundo. Kung ang resource ay nagbago nang dalawang beses sa loob ng isang segundo, maaaring makaligtaan ng client ang bagong bersyon. Sa praktika, ito ay bihirang scenario, ngunit para sa mga high-frequency na update (feed ng quotation, chat) ang ETag ay inirerekomenda. Ang pangalawang limitasyon ay problema sa clustering: sa iba't ibang server, ang file ay maaaring may iba't ibang mtime dahil sa pagkopya o deployment, na nagiging sanhi ng hindi pagkakatugma ng Last-Modified.

Ang ikatlong limitasyon — pagproseso ng If-Modified-Since na may katumpakan ng segundo ay maaaring humantong sa mga labis na kahilingan sa madalas na polling ng server. Kung ang client ay nagpapadala ng If-Modified-Since tuwing 500 ms, ang server ay bawat oras ay nagbabalik ng 200 OK, dahil hindi nagbago ang petsa, ngunit ang resource ay aktwal na na-update na. Ang solusyon ay kombinasyon sa ETag: mahuhuli ng ETag ang pagbabago sa loob ng isang segundo, habang ang Last-Modified ay mananatiling backup.

Ang ikaapat na problema — hindi pinag-iiba ng Last-Modified ang iba't ibang bersyon ng parehong resource na may parehong petsa. Kung ang file ay na-restore mula sa backup at ang mtime nito ay tumutugma sa orihinal, hindi mapapansin ng client na nagbago ang nilalaman. Nilulutas ng ETag ang problemang ito: ang hash ng nilalaman ay garantadong magbabago sa bawat pagbabago ng data, anuman ang time stamp. Para sa kritikal na data, laging gamitin ang parehong header.

• Katumpakan hanggang segundo — hindi nahuhuli ang mga pagbabago sa loob ng isang segundo; gumamit ng ETag para sa high-frequency na update
• Clustering — ang mtime ay maaaring magkaiba sa iba't ibang server; i-sync sa pamamagitan ng NTP o gumamit ng ETag
• Race condition — kung ang resource ay nagbago pagkatapos ipadala ang If-Modified-Since ngunit bago ang pagsusuri sa server
• Maling interpretasyon ng proxy — maaaring baguhin ng ilang proxy ang Last-Modified habang nagca-cache; nilulutas ng HTTPS ang problemang ito