Last-Modified — جوہر، میکانزم اور تبدیلی کی تاریخ کے ہیڈر کی ترتیب

Last-Modified کیا ہے؟

Last-Modified ایک HTTP ہیڈر ہے جو مشروط درخواست ہیڈرز کے گروپ سے تعلق رکھتا ہے۔ سرور اسے GET یا HEAD کے جواب میں شامل کرتا ہے، HTTP-date فارمیٹ میں درخواست کردہ وسائل کی آخری تبدیلی کی تاریخ اور وقت بتاتا ہے: Last-Modified: Wed, 02 Jul 2025 14:30:00 GMT۔ کلائنٹ (براؤزر، موبائل ایپ، پراکسی) اس تاریخ کو کیشڈ وسائل کے ساتھ محفوظ کرتا ہے۔ بار بار کی درخواست پر، کلائنٹ اسی تاریخ کے ساتھ If-Modified-Since ہیڈر بھیجتا ہے، اور سرور اس کا موازنہ وسائل کے موجودہ تبدیلی کے وقت سے کرتا ہے۔

Last-Modified کے ساتھ مشروط درخواستوں کا پروٹوکول RFC 7232 میں بیان کیا گیا ہے اور تمام جدید HTTP سرورز اسے سپورٹ کرتے ہیں۔ تاریخ کا فارمیٹ سختی سے منظم ہے — صرف GMT (گرین وچ مین ٹائم) بغیر ٹائم زون کے اشارے کے۔ سرور کو تین ممکنہ فارمیٹس میں تاریخ لوٹانی چاہیے: RFC 1123 (معیاری)، RFC 850 (قدیم) یا ANSI C asctime۔ عملی طور پر، تقریباً تمام سرور 29 حروف کی مقررہ لمبائی کے ساتھ RFC 1123 فارمیٹ استعمال کرتے ہیں۔

Last-Modified کیش توثیق کے طریقہ کار کے زمرے سے تعلق رکھتا ہے: یہ کلائنٹ کو نہیں بتاتا کہ رسپانس کیش کیا جا سکتا ہے یا نہیں، بلکہ پہلے سے کیش شدہ وسائل کی تازگی جانچنے کا ایک آلہ فراہم کرتا ہے۔ کیشنگ پالیسی Cache-Control ہیڈر کے ذریعے الگ سے طے کی جاتی ہے۔ Akamai (2025) کی ایک تحقیق کے مطابق، Last-Modified کو Cache-Control کے ساتھ درست ترتیب دینے سے سٹیٹک مواد کے لیے اوریجن سرور کے بوجھ کو 70% تک کم کیا جا سکتا ہے۔

Last-Modified کب ظاہر ہوا؟

Last-Modified ہیڈر HTTP/1.0 (RFC 1945, 1996) میں بیان کیا گیا تھا اور ویب پر کیشنگ کے انتظام کے پہلے طریقہ کار میں سے ایک بن گیا تھا۔ HTTP/1.1 میں ETag کے آنے سے پہلے، مشروط درخواستیں کرنے کا یہ واحد طریقہ تھا۔ عمر کے باوجود، یہ ہیڈر اپنی سادگی کی وجہ سے متعلقہ ہے — سرور کو مواد کا ہیش شمار کرنے کی ضرورت نہیں، صرف فائل سسٹم سے فائل کا ٹائم سٹیمپ یا ڈیٹا بیس سے updated_at فیلڈ پڑھنا کافی ہے۔

Last-Modified کیسے کام کرتا ہے؟

مکمل چکر تین مراحل پر مشتمل ہے۔ پہلی درخواست پر، سرور Last-Modified ہیڈر اور HTTP اسٹیٹس 200 OK کے ساتھ وسائل لوٹاتا ہے۔ کلائنٹ تاریخ کے ساتھ رسپانس کو کیش کرتا ہے۔ بار بار کی درخواست پر، کلائنٹ محفوظ کردہ تاریخ کے ساتھ If-Modified-Since ہیڈر بھیجتا ہے۔ سرور اس تاریخ کا موازنہ وسائل کے موجودہ تبدیلی کے وقت سے کرتا ہے۔ اگر وسائل تبدیل نہیں ہوا — خالی باڈی کے ساتھ 304 Not Modified لوٹاتا ہے۔ اگر تبدیل ہوا — نئے ڈیٹا اور نئے Last-Modified کے ساتھ 200 OK لوٹاتا ہے۔

// پہلی درخواست — سرور تاریخ کے ساتھ وسائل لوٹاتا ہے
HTTP/1.1 200 OK
Content-Type: application/json
Last-Modified: Wed, 02 Jul 2025 14:30:00 GMT

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

// بار بار کی درخواست — کلائنٹ محفوظ شدہ تاریخ بھیجتا ہے
GET /api/users HTTP/1.1
Host: example.com
If-Modified-Since: Wed, 02 Jul 2025 14:30:00 GMT

// جواب — ڈیٹا تبدیل نہیں ہوا
HTTP/1.1 304 Not Modified

موبائل ایپلی کیشنز کے لیے، Last-Modified ڈیٹا کی مطابقت پذیری کے لیے خاص طور پر مفید ہے۔ ایپلی کیشن آخری کامیاب اپ ڈیٹ کی تاریخ محفوظ کرتی ہے اور اسے If-Modified-Since میں سرور کو بھیجتی ہے۔ اگر مزید ڈیٹا ہے یا وہ تبدیل ہوا ہے — سرور مکمل سیٹ لوٹاتا ہے۔ اگر نہیں — 304، اور ایپلی کیشن مقامی کاپی استعمال کرتی ہے۔ OkHttp اور URLSession بلٹ ان کیشنگ سسٹمز کے ذریعے اس طریقہ کار کو خود بخود سپورٹ کرتے ہیں۔

سرور تاریخ کیسے طے کرتا ہے؟

سٹیٹک فائلوں کے لیے، Nginx اور Apache فائل سسٹم کی خصوصیات — mtime (تبدیلی کا وقت) — سے تاریخ لیتے ہیں۔ ڈائنامک مواد کے لیے، سرور کوڈ کو کاروباری منطق کی بنیاد پر واضح طور پر Last-Modified سیٹ کرنا چاہیے: ڈیٹا بیس سے updated_at فیلڈ، Git میں آخری commit کی تاریخ، بلڈ آرٹیفیکٹ کا ٹائم سٹیمپ۔ اگر Last-Modified واضح طور پر سیٹ نہیں کیا گیا تو سرور ہیڈر بالکل نہیں بھیج سکتا، اور کلائنٹ تاریخ کے مطابق مشروط درخواستیں نہیں کر سکے گا۔

Last-Modified بمقابلہ ETag

Last-Modified اور ETag ایک جیسا کام کرتے ہیں — کلائنٹ کو کیش کی تازگی جانچنے دینا — لیکن ان میں بنیادی فرق ہے۔ Last-Modified ٹائم سٹیمپ استعمال کرتا ہے، ETag ایک منفرد ورژن شناخت کنندہ استعمال کرتا ہے۔ ہر طریقہ کار کے اپنے منظرنامے ہیں جہاں یہ زیادہ مؤثر ہے، اور HTTP تفصیل دونوں ہیڈر کو ایک ساتھ استعمال کرنے کی سفارش کرتی ہے۔

Last-Modified کا بنیادی فائدہ سادگی ہے۔ سرور کو مواد کا ہیش شمار کرنے کی ضرورت نہیں، جو ہر درخواست پر CPU وسائل بچاتا ہے۔ سٹیٹک فائلوں یا واضح ٹائم سٹیمپ والے ڈیٹا کی خدمت کرنے والے زیادہ ٹریفک والے منصوبوں کے لیے، Last-Modified بہترین انتخاب ہے۔ دوسری طرف، ETag مطلق درستگی فراہم کرتا ہے — JSON رسپانس میں ایک حرف تبدیل کرنے سے ETag بدل جائے گا، لیکن تاریخ نہیں بدل سکتی (اگر فائل اسی ورژن کے ساتھ اوور رائٹ ہوئی تھی)۔

ایک ساتھ استعمال

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

سرور پر Last-Modified کی ترتیب

Last-Modified کی ترتیب سرور کی قسم پر منحصر ہے۔ Nginx اور Apache کے لیے، Last-Modified سٹیٹک فائلوں کے لیے mtime کی بنیاد پر خود بخود سیٹ ہوتا ہے۔ ڈائنامک ایپلی کیشنز کے لیے، ہیڈر کو سرور کوڈ میں سیٹ کرنا چاہیے۔ آئیے مقبول پلیٹ فارمز پر ترتیب دیکھتے ہیں۔

// Express.js — Last-Modified ترتیب دینا
app.get("/api/users", async (req, res) => {
    const updatedAt = await getLastUpdate()
    const ifModifiedSince = req.get("If-Modified-Since")

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

Express.js کی مثال میں، سرور ڈیٹا بیس سے ڈیٹا کی آخری اپ ڈیٹ کی تاریخ لیتا ہے، کلائنٹ سے If-Modified-Since چیک کرتا ہے، اور اگر کیش ابھی بھی تازہ ہے — 304 لوٹاتا ہے۔ اگر ڈیٹا تبدیل ہوا ہے — نیا Last-Modified سیٹ کرتا ہے اور مکمل رسپانس لوٹاتا ہے۔ toUTCString() تاریخ کو مطلوبہ HTTP فارمیٹ میں تبدیل کرتا ہے۔ پروڈکشن میں، ہر درخواست پر ڈیٹا بیس کی استفسار سے بچنے کے لیے Redis میں updatedAt کو کیش کرنا مفید ہے۔

Nginx: Last-Modified کی ترتیب

Nginx فائل کی آخری تبدیلی کے وقت کی بنیاد پر سٹیٹک فائلوں کے لیے خود بخود Last-Modified سیٹ کرتا ہے۔ etag ڈائریکٹیو (ETag کو غیر فعال کرنا) یا ngx_http_headers_module ماڈیول کے ذریعے اس رویے کو غیر فعال یا تبدیل کیا جا سکتا ہے۔ بیک اینڈ پر پراکسی کی گئی درخواستوں کے لیے، Last-Modified اپ اسٹریم رسپانس سے بغیر تبدیلی کے منتقل ہوتا ہے۔ اہم: اگر بیک اینڈ Last-Modified نہیں لوٹاتا، Nginx اسے ڈائنامک رسپانسز کے لیے خود بخود شامل نہیں کرے گا۔

حدود اور نقصانات

Last-Modified کی کئی معروف حدود ہیں۔ اہم سیکنڈ کی درستگی ہے۔ اگر کوئی وسائل ایک سیکنڈ کے اندر دو بار تبدیل ہوتا ہے، کلائنٹ نیا ورژن کھو سکتا ہے۔ عملی طور پر یہ ایک نایاب منظر نامہ ہے، لیکن زیادہ فریکوئنسی والی اپ ڈیٹس (ٹکر فیڈز، چیٹس) کے لیے ETag تجویز کیا جاتا ہے۔ دوسری حد کلسٹرنگ کا مسئلہ ہے: مختلف سرورز پر، کاپی یا ڈیپلائمنٹ کی وجہ سے فائل کا mtime مختلف ہو سکتا ہے، جس سے Last-Modified غیر مستقل ہو جاتا ہے۔

تیسری حد — If-Modified-Since کو سیکنڈ کی درستگی کے ساتھ ہینڈل کرنا بار بار سرور سے پولنگ کرتے وقت غیر ضروری درخواستوں کا سبب بن سکتا ہے۔ اگر کلائنٹ ہر 500 ms میں If-Modified-Since بھیجتا ہے، سرور ہر بار 200 OK لوٹاتا ہے کیونکہ تاریخ تبدیل نہیں ہوئی، لیکن وسائل حقیقت میں پہلے ہی اپ ڈیٹ ہو چکا ہے۔ حل ETag کے ساتھ امتزاج استعمال کرنا ہے: ETag ایک سیکنڈ کے اندر تبدیلی کو پکڑ لے گا، جبکہ Last-Modified فال بیک کے طور پر رہے گا۔

چوتھا مسئلہ — Last-Modified ایک ہی تاریخ کے ساتھ ایک ہی وسائل کے مختلف ورژن میں فرق نہیں کرتا۔ اگر کوئی فائل بیک اپ سے بحال کی جاتی ہے اور اس کا mtime اصل سے ملتا ہے، کلائنٹ کو پتہ نہیں چلے گا کہ مواد تبدیل ہوا ہے۔ ETag اس مسئلے کو حل کرتا ہے: مواد کا ہیش ٹائم سٹیمپ سے قطع نظر، ڈیٹا میں کسی بھی تبدیلی پر یقینی طور پر بدل جائے گا۔ اہم ڈیٹا کے لیے، ہمیشہ دونوں ہیڈر استعمال کریں۔

• سیکنڈ کی درستگی — ایک سیکنڈ کے اندر تبدیلیاں نہیں پکڑتا؛ زیادہ فریکوئنسی والی اپ ڈیٹس کے لیے ETag استعمال کریں
• کلسٹرنگ — mtime سرورز پر مختلف ہو سکتا ہے؛ NTP کے ذریعے ہم آہنگ کریں یا ETag استعمال کریں
• ریس کنڈیشن — اگر وسائل If-Modified-Since بھیجنے کے بعد لیکن سرور چیک سے پہلے تبدیل ہو
• پراکسی کی غلط تشریح — کچھ پراکسیز کیش کرتے وقت Last-Modified تبدیل کر سکتی ہیں؛ HTTPS حل کرتا ہے