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) के एक अध्ययन के अनुसार, Cache-Control के साथ Last-Modified का उचित कॉन्फ़िगरेशन स्टैटिक सामग्री के लिए मूल सर्वर लोड को 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 में अंतिम कमिट की तारीख, बिल्ड आर्टिफ़ैक्ट टाइमस्टैम्प। यदि 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 प्रारूप में परिवर्तित करता है। प्रोडक्शन में, हर अनुरोध पर डेटाबेस क्वेरी से बचने के लिए updatedAt को Redis में कैश करना उचित है।

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 मिलीसेकंड में If-Modified-Since भेजता है, तो सर्वर हर बार 200 OK लौटाता है क्योंकि तारीख नहीं बदली है, लेकिन संसाधन वास्तव में पहले ही अपडेट हो चुका है। समाधान ETag के साथ संयोजन का उपयोग करना है: ETag एक सेकंड के भीतर परिवर्तन को पकड़ लेगा, जबकि Last-Modified आरक्षित के रूप में रहेगा।

चौथी समस्या — Last-Modified समान तारीख वाले एक ही संसाधन के विभिन्न संस्करणों में अंतर नहीं करता है। यदि कोई फ़ाइल बैकअप से पुनर्स्थापित की जाती है और उसका mtime मूल से मेल खाता है, तो क्लाइंट को पता नहीं चलेगा कि सामग्री बदल गई है। ETag इस समस्या को हल करता है: सामग्री हैश टाइमस्टैम्प की परवाह किए बिना डेटा में किसी भी बदलाव पर निश्चित रूप से बदल जाएगा। महत्वपूर्ण डेटा के लिए, हमेशा दोनों हेडर का उपयोग करें।

• सेकंड परिशुद्धता — एक सेकंड के भीतर परिवर्तन नहीं पकड़ता; उच्च-आवृत्ति अपडेट के लिए ETag का उपयोग करें
• क्लस्टरिंग — mtime सर्वरों पर भिन्न हो सकता है; NTP के माध्यम से सिंक करें या ETag का उपयोग करें
• रेस कंडीशन — यदि संसाधन If-Modified-Since भेजने के बाद लेकिन सर्वर जांच से पहले बदलता है
• प्रॉक्सी गलत व्याख्या — कुछ प्रॉक्सी कैश करते समय Last-Modified बदल सकते हैं; HTTPS इसे हल करता है