ETag: یہ کیا ہے، کیشنگ میکانزم اور ہیڈر کنفیگریشن

ETag کیا ہے؟

ETag (Entity Tag) ایک HTTP جوابی ہیڈر ہے جس میں وسائل کے ایک مخصوص ورژن کے لیے ایک منفرد شناخت کنندہ ہوتا ہے۔ سرور فائل کے مواد، اس کے میٹا ڈیٹا یا نظرثانی نمبر کی بنیاد پر ETag کا حساب لگاتا ہے اور GET درخواست کے جواب میں اسے کلائنٹ کو بھیجتا ہے۔ کلائنٹ اس شناخت کنندہ کو محفوظ کرتا ہے اور اسی وسائل پر بعد کی درخواستوں میں اسے If-None-Match ہیڈر میں بھیجتا ہے۔ اگر وسائل تبدیل نہیں ہوا تو سرور 304 Not Modified کے ساتھ جواب دیتا ہے اور کلائنٹ اپنی کیش کردہ کاپی استعمال کرتا ہے۔

ETag کی شکل RFC 7232 میں اقتباس مارکس میں ایک سٹرنگ کے طور پر بیان کی گئی ہے: "33a64df551425fcc55e4d42a148795d9f25f89d4"۔ قیمت فائل کے مواد کا SHA-1 ہیش، ایک بڑھتا ہوا ورژن نمبر، سٹیٹک فائلوں کے لیے inode-نمبر-وقت کا مجموعہ، یا سرور کے ذریعے تیار کردہ ایک صوابدیدی ٹوکن ہو سکتی ہے۔ واحد ضرورت یہ ہے کہ جب وسائل تبدیل ہو تو قیمت تبدیل ہونی چاہیے اور اگر وسائل یکساں رہے تو تبدیل نہیں ہونی چاہیے۔

ETag مشروط درخواست کے طریقہ کار (conditional requests) سے تعلق رکھتا ہے — HTTP پروٹوکول کی بنیادی اصلاحات میں سے ایک۔ غیر مشروط درخواستوں کے برعکس جہاں سرور ہمیشہ مکمل جواب لوٹاتا ہے، ایک مشروط درخواست کلائنٹ کو ڈیٹا دوبارہ لوڈ کیے بغیر کیش کی مطابقت جانچنے کی اجازت دیتی ہے۔ HTTP Archive (2025) کے مطابق، تمام HTTP جوابات میں سے تقریباً 40% 304 Not Modified ہیں، جو مناسب ETag اور Last-Modified کنفیگریشن کی بدولت ہے۔

ETag کہاں استعمال ہوتا ہے

ETag REST API میں ڈیٹا کلیکشن کی لوڈنگ کو بہتر بنانے کے لیے استعمال ہوتا ہے — اگر آبجیکٹ کی فہرست تبدیل نہیں ہوئی تو کلائنٹ پورا JSON منتقل کیے بغیر 304 وصول کرتا ہے۔ سٹیٹک فائلوں (CSS, JS, تصاویر) کے لیے، ETag CDNs اور براؤزرز کو کیش کی تازگی کو مؤثر طریقے سے جانچنے کی اجازت دیتا ہے۔ موبائل ایپلیکیشنز میں، ETag بیک گراؤنڈ سنکرونائزیشن کے لیے اہم ہے: ایپ چیک کرتی ہے کہ آیا سرور پر ڈیٹا تبدیل ہوا ہے اور صرف ضرورت ہونے پر اپ ڈیٹ ڈاؤن لوڈ کرتی ہے۔ یہ ٹریفک اور ڈیوائس کی بیٹری بچاتا ہے۔

ETag کیسے کام کرتا ہے؟

مکمل ETag لائف سائیکل چار مراحل پر مشتمل ہے۔ سرور پہلی درخواست پر ETag تیار کرتا ہے اور اسے جوابی ہیڈر میں لوٹاتا ہے۔ کلائنٹ ETag کو کیش کردہ وسائل کے ساتھ محفوظ کرتا ہے۔ بار بار کی درخواست پر، کلائنٹ If-None-Match ہیڈر کو محفوظ کردہ ETag قیمت کے ساتھ بھیجتا ہے۔ سرور موصولہ قیمت کا موجودہ وسائل ETag سے موازنہ کرتا ہے: مماثلت کی صورت میں، یہ خالی باڈی کے ساتھ 304 Not Modified لوٹاتا ہے؛ عدم مماثلت کی صورت میں، یہ نئے وسائل اور نئے ETag کے ساتھ 200 OK لوٹاتا ہے۔

// If-None-Match کے ساتھ کلائنٹ کی درخواست
GET /api/users HTTP/1.1
Host: example.com
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

// سرور کا جواب — وسائل تبدیل نہیں ہوا
HTTP/1.1 304 Not Modified
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

موبائل ایپلیکیشن میں، یہ چکر کیشنگ سپورٹ والے HTTP کلائنٹ کے ذریعے لاگو کیا جا سکتا ہے۔ مثال کے طور پر، OkHttp CacheInterceptor کے ذریعے خود بخود ETag کا انتظام کرتا ہے: یہ جوابی ETag محفوظ کرتا ہے اور بار بار کی درخواستوں پر If-None-Match شامل کرتا ہے۔ 304 وصول کرنے پر، OkHttp کیش کردہ ڈیٹا لوٹاتا ہے۔ OkHttp اضافی کنفیگریشن کے بغیر ETag کو سپورٹ کرتا ہے — بس OkHttpClient.Builder.cache() کے ذریعے کیش فعال کریں۔

سرور پر ETag جنریشن

سرور ETags کا حساب مختلف طریقوں سے لگا سکتا ہے: مواد کے MD5 یا SHA ہیش کے ذریعے، ڈیٹابیس سے نظرثانی نمبر کے ذریعے (مثلاً MySQL سے updated_at)، سٹیٹک فائلوں کے لیے inode + mtime + سائز کے مجموعے کے ذریعے (Nginx اسی طرح ETags تیار کرتا ہے)۔ متحرک APIs کے لیے، کنٹینٹ ہیش سب سے بھروسہ مند ہے: اگر JSON جواب میں ایک فیلڈ بھی تبدیل ہو جائے تو ETag تبدیل ہو جائے گا۔ تاہم، ہر درخواست پر ہیش کا حساب لگانا CPU پر بوجھ ڈالتا ہے — زیادہ بوجھ والے سسٹمز کے لیے، بڑھتا ہوا ورژن نمبر استعمال کرنا بہتر ہے۔

مضبوط اور کمزور ETag

RFC 7232 دو قسم کے ETags کی وضاحت کرتا ہے: مضبوط (strong) اور کمزور (weak)۔ مضبوط ETag کا مطلب ہے کہ وسائل کی دو نمائندگییں بائٹ بہ بائٹ ایک جیسی ہیں — ایک بٹ بھی مختلف نہیں۔ کمزور ETag (سابقہ W/) صرف معنوی مساوات کی ضمانت دیتا ہے: مواد سیریلائزیشن کی سطح (خالی جگہیں، JSON فیلڈ ترتیب) پر مختلف ہو سکتا ہے، لیکن ڈیٹا کلائنٹ کے لیے ایک جیسا سمجھا جاتا ہے۔ کمزور ETags کو W/ سابقہ سے نشان زد کیا جاتا ہے، مثال کے طور پر W/"1a2b3c"۔

ETag قسم کا انتخاب موازنہ کی درستگی کی ضروریات پر منحصر ہے۔ سٹیٹک فائلوں (CSS, JS, تصاویر) کے لیے، مضبوط ETags ترجیحی ہیں — اگر فائل تبدیل ہو گئی ہے تو کلائنٹ کو نیا ورژن ملنا چاہیے۔ متحرک APIs کے لیے، جہاں ایک ہی JSON کو مختلف فیلڈ ترتیب یا فارمیٹنگ کے ساتھ سیریلائز کیا جا سکتا ہے، کمزور ETags زیادہ لچک فراہم کرتے ہیں: سرور سٹرنگ نمائندگی کے بجائے کاروباری ڈیٹا کی بنیاد پر ETag تیار کرتا ہے۔

کمزور ETags کی ایک حد: یہ رینج درخواستوں (Range requests) کے ساتھ استعمال نہیں ہو سکتے۔ اگر کلائنٹ فائل کا ایک حصہ درخواست کرتا ہے، تو سرور کو اس بات کی ضمانت دینے کے لیے مضبوط ETag لوٹانا چاہیے کہ ٹکڑا مکمل وسائل سے مطابقت رکھتا ہے۔ کمزور ETags ایسی ضمانت نہیں دیتے۔ دیگر منظرناموں میں، کمزور ETags محفوظ ہیں اور APIs کے لیے تجویز کیے جاتے ہیں۔

ETag بمقابلہ Last-Modified

ETag اور Last-Modified مشروط درخواستوں کے لیے دو HTTP ہیڈر ہیں جو اکثر ایک ساتھ استعمال ہوتے ہیں۔ Last-Modified کسی وسائل کی آخری تبدیلی کی تاریخ بتاتا ہے اور If-Modified-Since ہیڈر کے ساتھ کام کرتا ہے۔ ETag ایک منفرد ورژن شناخت کنندہ فراہم کرتا ہے اور If-None-Match کے ساتھ کام کرتا ہے۔ ہر ایک کے اپنے فوائد اور حدود ہیں، اور انہیں یکجا کرنے سے زیادہ سے زیادہ کیشنگ کارکردگی ملتی ہے۔

Last-Modified لاگو کرنا آسان ہے — سرور خود بخود فائل سسٹم سے تاریخ حاصل کرتا ہے یا ڈیٹابیس میں updated_at فیلڈ کو اپ ڈیٹ کرتا ہے۔ تاہم، تاریخ میں سیکنڈ کی سطح کی درستگی ہے، جو ان وسائل کے لیے ناکافی ہے جو سیکنڈ میں کئی بار تبدیل ہوتے ہیں۔ مزید برآں، Last-Modified مختلف حالتوں میں فرق نہیں کرتا: اگر ایک فائل اسی ورژن سے اوور رائٹ ہو جائے تو تاریخ بدل جاتی ہے لیکن مواد نہیں بدلتا، لہذا کلائنٹ ایک جیسا ڈیٹا دوبارہ لوڈ کرے گا۔

ETag زیادہ درست ہے: یہ صرف اس وقت تبدیل ہوتا ہے جب مواد حقیقت میں تبدیل ہوتا ہے۔ اگر سرور بیک اپ سے پچھلا ورژن بحال کرتا ہے تو ETag بدل جاتا ہے۔ اگر ایک فائل اسی ڈیٹا سے اوور رائٹ ہو جائے تو ETag وہی رہتا ہے اور کلائنٹ دوبارہ لوڈ نہیں کرتا۔ مشترکہ استعمال HTTP تفصیلات کے ذریعے تجویز کیا جاتا ہے: سرور دونوں ہیڈر لوٹاتا ہے، کلائنٹ If-None-Match اور If-Modified-Since ایک ساتھ بھیجتا ہے۔ اگر کم از کم ایک ہیڈر تبدیلی کی نشاندہی کرتا ہے تو سرور نیا وسائل لوٹاتا ہے۔

ہیڈر کی ترجیح

تفصیلات کے مطابق، ETag کو Last-Modified پر ترجیح حاصل ہے۔ اگر سرور کو If-None-Match ملتا ہے تو اسے If-Modified-Since کو نظر انداز کرتے ہوئے صرف ETag چیک کرنا چاہیے۔ یہ دوڑ کی کیفیت (race condition) کو روکتا ہے: اگر کلائنٹ کے Last-Modified بھیجنے اور سرور پر چیک کرنے کے درمیان وسائل تبدیل ہو جائے تو ETag تازہ ترین اشارہ ہوگا۔ عملی طور پر، سرور عام طور پر دونوں ہیڈر چیک کرتے ہیں، لیکن جب نتائج میں تضاد ہو تو ETag جیت جاتا ہے۔

سرور پر ETag کا نفاذ

ETag کنفیگریشن سرور کی قسم پر منحصر ہے۔ Nginx سٹیٹک فائلوں کے لیے خود بخود inode، mtime اور سائز کی بنیاد پر ETags تیار کرتا ہے۔ Apache FileETag میکانزم استعمال کرتا ہے۔ Node.js، PHP، Python، Ruby پر متحرک ایپلیکیشنز کے لیے، ETags کو پروگرام کے ذریعے تیار کرنے کی ضرورت ہے — جوابی ہیش، ڈیٹا ورژن نمبر، یا درخواست کے پیرامیٹرز کے مجموعے کے ذریعے۔

func etagMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter,
        r *http.Request) {
        // ڈیٹا کی بنیاد پر ETag جنریشن
        etag := generateETag(r.URL.Path)
        w.Header().Set("ETag", etag)

        // If-None-Match کی جانچ
        if r.Header.Get("If-None-Match") == etag {
            w.WriteHeader(http.StatusNotModified)
            return
        }
        next.ServeHTTP(w, r)
    })
}

Go میں Middleware درخواست کو روکتا ہے، درخواست کردہ URL کے لیے ETag تیار کرتا ہے (مثال کے طور پر، کیش یا DB سے ڈیٹا ہیش کا حساب لگاتا ہے) اور جوابی ہیڈر سیٹ کرتا ہے۔ اگر کلائنٹ نے If-None-Match بھیجا ہے اور یہ موجودہ ETag سے مماثل ہے تو سرور مرکزی ہینڈلر کو کال کیے بغیر فوری طور پر 304 Not Modified لوٹاتا ہے۔ پروڈکشن میں، سرور کے بوجھ کو کم کرنے کے لیے URL اور پیرامیٹرز کے حساب سے شمار شدہ ETags کی کیشنگ شامل کرنی چاہیے۔

مسائل اور خطرات

ملٹی سرور کنفیگریشن (round-robin یا anycast) میں، ETag ایک ہی وسائل کے لیے تمام نوڈس پر ایک جیسا ہونا چاہیے۔ اگر ETag فائل inode کی بنیاد پر تیار کیا جائے اور سائٹ متعدد سرورز پر تعینات ہو تو قدریں مختلف ہوں گی۔ حل کنٹینٹ ہیش یا مرکزی ورژن سٹوریج (Redis, etcd) استعمال کرنا ہے۔ دوسرا مسئلہ gzip کمپریشن ہے: جب کمپریشن فعال ہوتا ہے تو Nginx ETag تبدیل کرتا ہے، جو بے کار 304 جوابات کا سبب بن سکتا ہے۔ کمپریسڈ مواد کے ساتھ ETag کو ہم آہنگ کرنے کے لیے gzip_vary on ترتیب دینا ضروری ہے۔