Az ETag vagy entitáscímke az RFC 7232 specifikáció által szabályozott HTTP/1.1 protokoll egyik szolgáltatásfejléce , amelyet a webszerver állíthat be a klienstől kapott kérésre adott válasz generálásának fázisában . Az ETag fejléc tartalma egy azonosító, amelynek értéke közvetlenül függ a kliens által betöltött erőforrás állapotától. A jövőben ezt az azonosítót használják a letöltött erőforrás állapotának frissítésére a webszerveren található eredeti állapotra . Ezt úgy érik el, hogy egy kérést küldenek a HTTP/1.1 szervernek , amelyben az ETag azonosítót adják meg fejlécértékként - If-None-Match . A szerver, miután talált egy ilyen fejlécet, az értékének az erőforrás aktuális állapotával való összevetése alapján tájékoztatja a klienst, hogy a kliens gyorsítótárában tárolt másolat naprakész, pl. nincs szükség újbóli letöltésre, vagy egyébként, le kell töltenie a legújabb verziót.
Az ETag egy privát azonosító, amelyet egy webszerver rendelt az URL-ben található erőforrás egy adott verziójához. Ha az ehhez a címhez tartozó erőforrás tartalma újra változik, akkor új ETag kerül hozzárendelésre. Az ETag-ek ilyen módon történő használata hasonló az ujjlenyomatok használatához, így gyorsan összehasonlíthatja és megállapíthatja, hogy egy erőforrás két verziója megegyezik-e vagy sem. Az ETag-ek összehasonlítása csak az azonos URL -ből származó Etage-ekkel van értelmes , a különböző URL-ekről származó azonosítók lehetnek egyenlőek, de nem feltétlenül azonosak, függetlenül az erőforrásoktól, így nincs értelme az összehasonlításuknak.
Az ETag-ek használata a HTTP -fejlécekben nem kötelező (mint néhány más HTTP 1.1-fejlécmező is). Az ET-címkék létrehozásának módszere soha nem volt megadva a HTTP-specifikációban.
Az ETag létrehozásának általános módszerei közé tartozik az erőforrás tartalmának ütközésálló hash függvénye , az utolsó módosítási idő hash-je vagy akár csak egy verziószám.
Az elavult gyorsítótár-adatok használatának elkerülése érdekében az ETag-ek generálására használt módszereknek biztosítaniuk kell (amennyire lehetséges), hogy minden ETag egyedi legyen. Azonban egy Etag-létrehozó függvény akkor tekinthető „hasznosnak”, ha (matematikailag) bizonyítható, hogy azonos ETag-ek létrehozása „elfogadhatóan ritka”, még akkor is, ha előfordul, vagy előfordul.
Egyes korai vezérlési funkciók, mint például a CRC32 és a CRC64, ismerten szenvednek ettől az ütközési problémától . Emiatt nem alkalmasak az ETag generálására.
Az ETag mechanizmus támogatja az erős és gyenge ellenőrzéseket is. Megkülönböztetik őket egy vezető W/ETag azonosító jelenléte, pl. "123456789"(erős ETag ellenőrzés), W/"123456789"(gyenge ETag ellenőrzés).
Az erős ETag-ellenőrzés ellenőrzi, hogy a tartalom mindkét erőforrásban bájtonként megegyezik-e, és az összes többi mező (például a Content-Language) megegyezik-e. Az erős ETag-ek lehetővé teszik a részleges válaszok gyorsítótárazását és összeállítását, akárcsak a bájttartomány-kérések esetében.
A gyenge ETag ellenőrzés csak azt ellenőrzi, hogy két erőforrás szemantikailag egyenértékű-e, ami azt jelenti, hogy gyakorlati célokra felcserélhetők, és használhatók-e a gyorsítótárazott másolatok. Ezek az erőforrások azonban nem feltétlenül bájtról bájtra azonosak, így a gyenge ETag-ek nem alkalmasak bájttartomány kérésekre. A gyenge ETag-ek hasznosak lehetnek olyan esetekben, amikor az erős ETag-ek webszerver általi létrehozása nem praktikus, például dinamikusan előállított tartalom esetén.
Normál használat esetén az URL lekérésekor a webszerver visszaadja az erőforrást a megfelelő ETag értékkel együtt, amely a HTTP mezőben található ETag:
ETag: "686897696a7c876b7e"
Az ügyfél ezután gyorsítótárba helyezheti az erőforrást az ETag-jével együtt. Később, ha a kliens ugyanarról a címről szeretne egy oldalt, akkor elküldi annak egy korábban elmentett ETag másolatát a kéréssel együtt If-None-Match.
If-None-Match: "686897696a7c876b7e"
A következő kérés során a kiszolgáló összehasonlíthatja az ügyfél ETag-jét az erőforrás aktuális verziójának ETag-jével. Ha az ETag értékek egyeznek, ami azt jelenti, hogy az erőforrás nem változott, a szerver nagyon rövid választ küldhet vissza 304 Nem módosítva HTTP-állapottal . A 304-es állapot jelzi az ügyfélnek, hogy a gyorsítótár verziója még mindig naprakész, és használnia kell.
Ha azonban az ETag értékei nem egyeznek, vagyis az erőforrás valószínűleg megváltozott, akkor a teljes válasz, beleértve az erőforrás tartalmát is, úgy jelenik meg, mintha az ETag-et nem használták volna. Ebben az esetben az ügyfél dönthet úgy, hogy lecseréli a gyorsítótárban lévő erőforrás-verziót az újonnan visszaadott verzióra és az új ETag-re.
Az ETag weboldalakon használható változásfigyelésre és értesítésekre. A weboldalak hatékony megfigyelését hátráltatja, hogy a legtöbb webhely nem állítja be az Etag fejlécet a weboldalakon. Ha a webfigyelőnek fogalma sincs arról, hogy a webtartalom módosult-e, akkor az összes tartalmat le kell kérni és elemezni kell mind a tartalom közzétevőjének, mind pedig annak, aki meg akarja tekinteni a számítási erőforrások segítségével.
Az ETag-ek segítségével nyomon követhetők az egyedi felhasználók [1] , mivel a HTTP-cookie -kat törölhetik az adatvédelemre törekvő felhasználók. 2011 júliusában Ashkan Soltani és az UC Berkeley kutatócsoportja arról számolt be, hogy számos webhely, köztük a Hulu.com, az ETag segítségével követte nyomon az ilyen célpontokat [2] . A Hulu és a KISSmetrics 2011. július 29-től [3] leállította ezt, mivel a KISSmetrics és több mint 20 ügyfele csoportos pert indít az „eltávolíthatatlan” nyomkövető cookie-k használata miatt, amelyek részben az ETag használatához kapcsolódnak [4]. .
| HTTP | |
|---|---|
| Általános fogalmak |
|
| Mód | |
| Címek |
|
| Állapotkódok | |