ETag और सशर्त अनुरोध: कैश की जाँच और बदलाव की सुरक्षा
कैश के लिए If-None-Match और नई सामग्री को अनजाने में बदलने से बचाने के लिए If-Match का सही प्रयोग करें।
इस पृष्ठ पर
संक्षिप्त उत्तर
ETag किसी संसाधन के एक खास निरूपण का सत्यापन मान है। पढ़ते समय ग्राहक मिला हुआ मान If-None-Match में और बदलते समय If-Match में भेज सकता है। GET या HEAD पर If-None-Match का मिलान होने से 304 Not Modified मिल सकता है और पहले से रखा हुआ उत्तर फिर इस्तेमाल होता है। If-Match की शर्त पूरी न हो तो 412 Precondition Failed मिलता है। तब वर्तमान सामग्री दोबारा पढ़कर बदलाव मिलाने चाहिए। दोनों प्रक्रियाओं का उद्देश्य अलग है। ETag पहुँच की अनुमति नहीं देता और किसी उपयोगकर्ता की निजी सामग्री दूसरे उपयोगकर्ताओं के साथ साझा करने की अनुमति भी नहीं है।
ETag किस निरूपण को पहचानता है
ETag चुने हुए निरूपण से संबंधित होता है, केवल URL से नहीं। सर्वर उसका मान चुनता है और ग्राहक उसे ऐसे पहचान मान की तरह रखता है जिसका अंदरूनी अर्थ नहीं निकालना चाहिए। वह फ़ाइल का हैश, समय या संस्करण संख्या होना आवश्यक नहीं है। उत्तर भाषा या दूसरे अनुरोध हेडर से बदलता हो तो वह चयन भी महत्त्वपूर्ण है। पहले पता करें कि कौन सा उत्तर रखा गया है और उसकी अपनी ETag कौन सी थी।
मिले हुए मान को जैसा है वैसा रखें
प्राप्त मान पूरा रखें, उद्धरण चिह्न और संभव W/ उपसर्ग सहित। उदाहरण में ETag: "version-a" है। उद्धरण हटाएँ नहीं, स्थानीय घड़ी से नया मान बनाएँ नहीं और नाम देखकर संस्करणों का क्रम तय न करें। सर्वर दूसरी योजना इस्तेमाल कर सकता है। हर सत्यापन मान को उसकी संबंधित सामग्री के साथ रखें। सभी संसाधनों के लिए एक सामान्य मान रखना या एक भाषा की सामग्री को दूसरी भाषा की ETag से जोड़ना गलत कैश व्यवहार पैदा कर सकता है।
HTTP/1.1 200 OK
ETag: "version-a"
Cache-Control: private, no-cache
Content-Type: application/json
{"title": "Example"}If-None-Match से कैश जाँचें
रखे हुए उत्तर की ताजगी जाँचनी हो तो उसकी ETag को GET अनुरोध के If-None-Match में भेजें। निरूपण अभी भी मिलता हो तो सर्वर 304 दे सकता है। बदल गया हो तो वह सामान्य रूप से सामग्री लौटाता है, अक्सर 200 और नई ETag के साथ। इससे सामग्री का दोबारा स्थानांतरण बच सकता है, लेकिन सर्वर अनुरोध फिर भी होता है। कैश नीति अनुमति दे तो ताजा उत्तर बिना इस जाँच के भी फिर इस्तेमाल किया जा सकता है।
GET /documents/42 HTTP/1.1
Host: example.com
If-None-Match: "version-a"304 पर पुरानी सामग्री न खोएँ
304 में नया निरूपण शरीर नहीं होता। पहले रखा हुआ शरीर बनाए रखें और आए हुए हेडर के अनुसार संबंधित कैश जानकारी अपडेट करें। खाली नेटवर्क शरीर आने पर पुराने दस्तावेज़ को खाली पाठ से न बदलें। यदि ग्राहक के पास संबंधित पुरानी सामग्री ही नहीं है तो केवल 304 से संसाधन नहीं बनाया जा सकता। शरीर पाने के लिए उचित नया अनुरोध करना होगा। संसाधन, चुना हुआ संस्करण, शरीर और सत्यापन मान की जोड़ी लगातार सही रखनी चाहिए।
HTTP/1.1 304 Not Modified
ETag: "version-a"
Cache-Control: private, no-cacheIf-Match से संपादन सुरक्षित करें
बदलाव करते समय उस संस्करण की ETag को If-Match में भेजें जिसे उपयोगकर्ता ने वास्तव में संपादित किया है। दूसरे लेखक ने संसाधन बदल दिया हो तो शर्त 412 से विफल हो सकती है। वर्तमान निरूपण फिर लें और बदलाव मिलाएँ; उसी लिखने के अनुरोध को बिना समझे न दोहराएँ। सर्वर को अपडेट के साथ शर्त सही ढंग से लागू करनी होगी। केवल इंटरफ़ेस में ETag दिखाना किसी दूसरे व्यक्ति का बदलाव खोने से बचाने के लिए पर्याप्त नहीं है।
PUT /documents/42 HTTP/1.1
Host: example.com
If-Match: "version-a"
Content-Type: application/json
Content-Length: 21
{"title": "Updated!"}मजबूत और कमजोर मान में अंतर
मजबूत सत्यापन मान बाइट स्तर की समानता बताता है। W/ वाला कमजोर मान कम कठोर समानता की अनुमति देता है। If-None-Match कमजोर तुलना करता है, जो कैश जाँच के लिए उपयोगी है। If-Match मजबूत तुलना करता है, इसलिए कमजोर ETag संपादन के लिए मिलती हुई मजबूत ETag नहीं बन जाती। W/ हटाने से नई गारंटी नहीं बनती। सेवा केवल कमजोर मान देती हो तो उसी सेवा का समर्थित संपादन नियंत्रण चुनें और सभी ETag को एक जैसा न समझें।
कैश की नीति साथ में तय करें
ETag, Cache-Control या Vary का स्थान नहीं लेता। Cache-Control कैश व्यवहार तय करता है और Vary बताता है कि कौन से अनुरोध हेडर निरूपण चुनने में प्रभाव डालते हैं। no-cache सामग्री रखने देता है, लेकिन दोबारा उपयोग से पहले जाँच चाहता है। no-store उत्तर रखने से रोकता है। व्यक्तिगत उत्तर के लिए निजी और साझा कैश की उचित नीति भी चाहिए। पहले तय करें कि उत्तर कौन रख सकता है और कब इस्तेमाल कर सकता है, फिर सत्यापन मान जोड़ें।
सशर्त अनुरोध की समस्या क्रम से समझें
पहले उत्तर का स्थिति कोड, ETag, Cache-Control और Vary देखें। फिर बिना बदले संसाधन और बदले निरूपण की सशर्त पढ़ाई की तुलना करें। संपादन विवाद में भेजे हुए If-Match और लौटे स्थिति कोड को जाँचें। संवेदनशील शरीर के बजाय संसाधन पहचान और स्थिति लिखना अधिक उपयुक्त है। HTTP ब्लॉक उदाहरण के आदान-प्रदान हैं, किए हुए नेटवर्क परीक्षण नहीं। यह क्रम गायब पुरानी सामग्री, गलत मान और शर्त अनदेखी करने वाले सर्वर में अंतर समझने में मदद करता है।
क्या जाँचें
- हर ETag उसकी सही संबंधित सामग्री के साथ रखें।
- 304 पर पुराना शरीर रखें, उसे खाली शरीर से न बदलें।
- 412 को संपादन विवाद मानें और दोबारा प्रयास से पहले नई सामग्री पढ़ें।
- Cache-Control, Vary और मजबूत या कमजोर ETag को एक साथ जाँचें।
उपयोग की सीमाएँ
ग्राहक को सामग्री सही रखनी और सर्वर को शर्त लागू करनी होगी। सशर्त अनुरोध अनुमति, गोपनीयता या विवाद हल करने की पूरी नीति नहीं देते। उदाहरण HTTP समझाते हैं; डेटा स्थानांतरण की बचत मापी नहीं गई है।