ETag: ano ito, mekanismo ng caching at pagsasaayos ng header

Ano ang ETag?

ETag (Entity Tag) — ay isang HTTP response header na naglalaman ng natatanging identifier ng isang tiyak na bersyon ng resource. Kinakalkula ng server ang ETag batay sa nilalaman ng file, metadata nito, o numero ng rebisyon at ipinapadala ito sa client bilang tugon sa isang GET request. Iniimbak ng client ang identifier na ito at sa mga susunod na kahilingan sa parehong resource ay ipinapadala ito sa header na If-None-Match. Kung hindi nagbago ang resource, tumugon ang server ng 304 Not Modified, at ginagamit ng client ang naka-cache nitong kopya.

Ang format ng ETag ay tinukoy sa RFC 7232 bilang isang string sa mga panipi: "33a64df551425fcc55e4d42a148795d9f25f89d4". Ang halaga ay maaaring isang SHA-1 hash ng nilalaman ng file, isang inkremental na numero ng bersyon, isang kumbinasyon ng inode-numero-oras para sa mga static na file, o isang arbitraryong token na binuo ng server. Ang tanging kinakailangan ay ang halaga ay dapat magbago sa bawat pagbabago ng resource at hindi magbago kung ang resource ay nananatiling pareho.

Ang ETag ay kabilang sa mekanismo ng kondisyonal na mga kahilingan (conditional requests) — isa sa mga pangunahing optimisasyon ng HTTP protocol. Hindi tulad ng walang kondisyong mga kahilingan kung saan ang server ay palaging nagbabalik ng kumpletong tugon, ang isang kondisyonal na kahilingan ay nagpapahintulot sa client na suriin ang pagiging bago ng cache nang hindi muling nagda-download ng data. Ayon sa data ng HTTP Archive (2025), humigit-kumulang 40% ng lahat ng HTTP na tugon ay 304 Not Modified dahil sa tamang pagsasaayos ng ETag at Last-Modified.

Saan ginagamit ang ETag

Ang ETag ay ginagamit sa REST API para i-optimize ang pag-load ng mga koleksyon ng data — kung ang listahan ng mga bagay ay hindi nagbago, ang client ay tumatanggap ng 304 nang hindi nagpapadala ng buong JSON. Sa mga static na file (CSS, JS, mga larawan) pinapayagan ng ETag ang mga CDN at browser na mahusay na suriin ang pagiging bago ng cache. Sa mga mobile application, ang ETag ay kritikal para sa background synchronization: sinusuri ng application kung nagbago ang data sa server at nagda-download lamang ng mga update kung kinakailangan. Ito ay nakakatipid ng bandwidth at baterya ng device.

Paano gumagana ang ETag?

Ang kumpletong siklo ng paggana ng ETag ay binubuo ng apat na hakbang. Ang server ay lumilikha ng ETag sa unang kahilingan at ibinabalik ito sa header ng tugon. Iniimbak ng client ang ETag kasama ang naka-cache na resource. Sa paulit-ulit na kahilingan, ipinapadala ng client ang header na If-None-Match na may halaga ng naka-save na ETag. Inihahambing ng server ang natanggap na halaga sa kasalukuyang ETag ng resource: kung magkatugma, ibinabalik ang 304 Not Modified na may walang laman na body, kung hindi magkatugma — 200 OK na may bagong resource at bagong ETag.

// Kahilingan ng client na may If-None-Match
GET /api/users HTTP/1.1
Host: example.com
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

// Tugon ng server — hindi nagbago ang resource
HTTP/1.1 304 Not Modified
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Sa isang mobile application, ang siklong ito ay maaaring ipatupad sa pamamagitan ng HTTP client na may suporta sa cache. Ang OkHttp, halimbawa, ay awtomatikong namamahala ng ETag sa pamamagitan ng CacheInterceptor: iniimbak nito ang ETag ng tugon at sa paulit-ulit na kahilingan ay nagdaragdag ng If-None-Match. Sa pagtanggap ng 304, ibinabalik ng OkHttp ang naka-cache na data. OkHttp ay sumusuporta sa ETag nang walang karagdagang pagsasaayos — sapat na upang paganahin ang cache sa pamamagitan ng OkHttpClient.Builder.cache().

Pagbuo ng ETag sa server

Ang server ay maaaring kalkulahin ang ETag sa iba’t ibang paraan: sa pamamagitan ng MD5 o SHA hash ng nilalaman, sa pamamagitan ng numero ng rebisyon mula sa database (halimbawa, updated_at mula sa MySQL), sa pamamagitan ng kumbinasyon ng inode + mtime + size para sa mga static na file (Ang Nginx ay lumilikha ng ETag nang eksakto sa ganitong paraan). Para sa mga dynamic na API, ang pinaka-maaasahan ay ang hash ng nilalaman: kung ang JSON na tugon ay nagbago ng kahit isang field, magbabago ang ETag. Gayunpaman, ang pagkalkula ng hash sa bawat kahilingan ay nagpapabigat sa CPU — para sa mga system na may mataas na karga, mas mainam na gumamit ng inkremental na numero ng bersyon.

Malakas at mahinang ETag

Tinutukoy ng RFC 7232 ang dalawang uri ng ETag: malakas (strong) at mahina (weak). Ang malakas na ETag ay nangangahulugan na ang dalawang representasyon ng resource ay magkapareho byte-por-byte — walang kahit isang bit na naiiba. Ang mahinang ETag (prefix W/) ay ginagarantiyahan lamang ang semantikong pagkakatumbas: ang nilalaman ay maaaring magkaiba sa antas ng serialisasyon (mga puwang, pagkakasunud-sunod ng mga field ng JSON), ngunit ang data ay itinuturing na pareho para sa client. Ang mga mahinang ETag ay minarkahan ng prefix W/, halimbawa W/"1a2b3c".

Ang pagpili ng uri ng ETag ay depende sa mga kinakailangan sa katumpakan ng paghahambing. Para sa mga static na file (CSS, JS, mga larawan) ang malakas na ETag ay ginusto — kung nagbago ang file, dapat matanggap ng client ang bagong bersyon. Para sa mga dynamic na API, kung saan ang parehong JSON ay maaaring i-serialize na may iba’t ibang pagkakasunud-sunod ng field o formatting, ang mga mahinang ETag ay nagbibigay ng higit na kakayahang umangkop: ang server ay lumilikha ng ETag batay sa data ng negosyo, hindi sa representasyon ng string.

Limitasyon ng mga mahinang ETag: hindi sila maaaring gamitin sa mga kahilingan ng saklaw (Range requests). Kung humihiling ang client ng bahagi ng file, dapat magbalik ang server ng malakas na ETag upang garantiya na ang fragment ay tumutugma sa buong resource. Ang mga mahinang ETag ay hindi nagbibigay ng gayong garantiya. Sa iba pang senaryo, ang mga mahinang ETag ay ligtas at inirerekomenda para sa mga API.

ETag vs Last-Modified

Ang ETag at Last-Modified ay dalawang HTTP header para sa kondisyonal na mga kahilingan na kadalasang ginagamit nang magkasama. Ipinapahiwatig ng Last-Modified ang petsa ng huling pagbabago ng resource at gumagana sa header na If-Modified-Since. Nagbibigay ang ETag ng natatanging identifier ng bersyon at gumagana sa If-None-Match. Bawat isa ay may kanya-kangang pakinabang at limitasyon, at ang kumbinasyon ay nagbibigay ng maximum na kahusayan ng caching.

Last-Modified ay mas simple na ipatupad — awtomatikong nakukuha ng server ang petsa mula sa file system o ina-update ang field na updated_at sa database. Gayunpaman, ang petsa ay may katumpakan hanggang sa segundo, na hindi sapat para sa mga resource na nagbabago ng ilang beses bawat segundo. Bukod pa rito, hindi nakikilala ng Last-Modified ang iba’t ibang estado: kung ang file ay na-overwrite ng parehong bersyon, nagbabago ang petsa, ngunit ang nilalaman ay hindi — muling naglo-load ang client ng magkaparehong data.

ETag ay mas tumpak: nagbabago lamang ito sa aktwal na pagbabago ng nilalaman. Kung ibinalik ng server ang nakaraang bersyon mula sa backup, magbabago ang ETag. Kung ang file ay na-overwrite ng parehong data — mananatiling pareho ang ETag, at hindi muling maglo-load ang client. Paggamit nang magkasama ay inirerekomenda ng HTTP specification: ang server ay nagbabalik ng parehong header, ang client ay nagpapadala ng If-None-Match at If-Modified-Since nang sabay. Kung kahit isang header ay nagpapakita ng pagbabago — ang server ay nagbabalik ng bagong resource.

Priyoridad ng mga header

Ayon sa specification, ang ETag ay may priyoridad kaysa sa Last-Modified. Kung nakatanggap ang server ng If-None-Match, dapat nitong suriin lamang ang ETag, hindi pinapansin ang If-Modified-Since. Pinipigilan nito ang race condition: kung nagbago ang resource sa pagitan ng pagpapadala ng Last-Modified ng client at ng pagsusuri sa server, ang ETag ay magiging mas bagong tagapagpahiwatig. Sa pagsasagawa, karaniwang sinusuri ng mga server ang parehong header, ngunit kung hindi magkatugma ang mga resulta, nananalo ang ETag.

Pagpapatupad ng ETag sa server

Ang pagsasaayos ng ETag ay depende sa uri ng server. Ang Nginx ay lumilikha ng ETag para sa mga static na file nang awtomatiko batay sa inode, mtime at laki. Ang Apache ay gumagamit ng FileETag na mekanismo. Para sa mga dynamic na application sa Node.js, PHP, Python, Ruby, ang ETag ay dapat na buuin nang programmatically — sa pamamagitan ng hash ng tugon, numero ng bersyon ng data, o kumbinasyon ng mga parameter ng kahilingan.

func etagMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter,
        r *http.Request) {
        // Pagbuo ng ETag batay sa data
        etag := generateETag(r.URL.Path)
        w.Header().Set("ETag", etag)

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

Ang middleware sa Go ay humarang ng kahilingan, lumilikha ng ETag para sa hiniling na URL (halimbawa, kinakalkula ang hash ng data mula sa cache o database) at itinatakda ang header ng tugon. Kung nagpadala ang client ng If-None-Match at ito ay tumutugma sa kasalukuyang ETag, ang server ay agad na nagbabalik ng 304 Not Modified, nang hindi tinatawagan ang pangunahing handler. Sa kapaligiran ng produksyon, nararapat na magdagdag ng caching ng mga nakalkulang ETag ayon sa URL at mga parameter upang mabawasan ang karga ng server.

Mga problema at patibong

Sa multi-server na pagsasaayos (round-robin o anycast) ang ETag ay dapat na pareho sa lahat ng node para sa parehong resource. Kung ang ETag ay binuo batay sa inode ng file, at ang site ay tumatakbo sa maraming server, ang mga halaga ay mag-iiba. Ang solusyon — paggamit ng hash ng nilalaman o sentralisadong pag-iimbak ng bersyon (Redis, etcd). Ang pangalawang problema — gzip compression: binabago ng Nginx ang ETag kapag naka-enable ang compression, na maaaring magdulot ng labis na 304. Kinakailangan ang pagsasaayos ng gzip_vary on para sa pag-sync ng ETag sa naka-compress na nilalaman.