दो अनुवर्ती अनुरोधों के लिए, निम्नलिखित दो शीर्षकों में से कौन सा ब्राउज़र ब्राउज़रों द्वारा अधिक वजन दिया जाता है उनमें से एक को बदलना चाहिए: ETag या Last-Modified?प्राथमिकता क्या है: ईटीएजी या अंतिम-संशोधित HTTP शीर्षलेख?
यह "OR" अभिव्यक्ति की तरह नहीं है। छद्म कोड में:
if ETagFromServer != ETagOnClient || LastModifiedFromServer != LastModifiedOnClient
GetFromServer
else
GetFromCache
अनुसार खंड 13.3.4 के लिए RFC 2616, एक HTTP 1.1 क्लाइंट किसी भी कैश-सशर्त अनुरोधों में ETag का उपयोग करना चाहिए, और अगर दोनों एक ETag और अंतिम संशोधन मौजूद हैं, यह दोनों का उपयोग करना चाहिए। ईटीएजी हेडर को एक मजबूत सत्यापनकर्ता माना जाता है (धारा 13.3.3 देखें), जब तक सर्वर द्वारा कमजोर घोषित नहीं किया जाता है, जबकि अंतिम संशोधित शीर्षलेख को कमजोर माना जाता है जब तक कि कम से कम एक मिनट का अंतर और दिनांक शीर्षलेख के बीच मौजूद न हो। नोट, हालांकि सर्वर को या तो भेजने की आवश्यकता नहीं है (लेकिन यह चाहिए, अगर यह कर सकता है)।
ध्यान दें कि ग्राहक हेडर को यह देखने के लिए जांच नहीं करता है कि वे बदल गए हैं या नहीं; यह सिर्फ अगले सशर्त अनुरोध में अंधेरे से उनका उपयोग करता है; यह अनुरोध करने के लिए सर्वर पर निर्भर है कि अनुरोधित सामग्री भेजना है या 304 संशोधित प्रतिक्रिया नहीं है। यदि सर्वर केवल एक भेजता है, तो ग्राहक अकेले उस का उपयोग करेगा (हालांकि, केवल मजबूत सत्यापनकर्ता एक रेंज अनुरोध के लिए उपयोगी हैं)। बेशक, यह मध्यवर्ती कैश के विवेकाधिकार पर भी है (जब तक उन्हें कैश नियंत्रण निर्देशों के माध्यम से कैशिंग से रोका नहीं जाता है) और सर्वर के रूप में वे शीर्षकों पर कैसे कार्य करेंगे; आरएफसी का कहना है कि यदि वैधकर्ता असंगत हैं, तो उन्हें 304 संशोधित नहीं करना चाहिए, लेकिन चूंकि सर्वर द्वारा हेडर मान उत्पन्न होते हैं, इसलिए इसमें काफी कम छूट होती है।
प्रैक्टिस में, मैंने देखा है कि क्रोम, फ़ायरफ़ॉक्स, और आईई 7+ सभी उपलब्ध होने पर दोनों शीर्षलेख भेजते हैं। संशोधित शीर्षलेख भेजते समय मैंने व्यवहार का भी परीक्षण किया, जिसे मैंने आरएफसी में जानकारी से पहले ही संदेह किया था। मैंने जिन चार क्लाइंटों का परीक्षण किया था, केवल तभी सशर्त अनुरोध भेजे गए थे जब पृष्ठ को रीफ्रेश किया गया हो या यदि पहली बार यह पृष्ठ वर्तमान प्रक्रिया द्वारा अनुरोध किया गया था।
ग्रेट उत्तर, थॉमस होना चाहिए। आधिकारिक विशिष्टता प्रदान करने और वर्तमान ब्राउज़र कार्यान्वयन पर चर्चा करने के लिए धन्यवाद। – dthrasher
सेक्शन 14.26 से उद्धरण, ** सर्वर को अनुरोधित विधि नहीं करनी चाहिए, जब तक ऐसा करने की आवश्यकता न हो क्योंकि संसाधन की संशोधन तिथि अनुरोध में विफल होने के बाद एक संशोधित-से-संशोधित हेडर फ़ील्ड में मेल खाने में विफल रहता है। ** दिखता है जैसे-संशोधित-चूंकि प्राथमिकता लेती है। – Vicary
=! सही तुलना ऑपरेटर है। क्लाइंट को सर्वर से प्राप्त शाब्दिक स्ट्रिंग को रखने की आवश्यकता होती है, क्योंकि रूपांतरण छोटे अंतर बना सकते हैं। आप यह नहीं मान सकते कि 'नया बेहतर है'।
क्यों? उस मामले पर विचार करें जहां सर्वर ऑपरेटर संसाधन के खराब संस्करण को उलट देता है। उलटा संस्करण OLDER है - लेकिन सही है।
क्लाइंट को वर्तमान में सर्वर द्वारा पेश किए गए संस्करण का उपयोग करना चाहिए; यह केवल कैश किए गए संस्करण का उपयोग कर सकता है यदि यह वही है। इस प्रकार सर्वर को समानता की जांच करनी चाहिए, न कि 'नया'।
मुझे लगता है कि अंतिम संशोधित टाइमस्टैम्प की तुलना अलग-अलग तुलना की जानी चाहिए, जैसे: अगर ETagFromServer! = ETagOnClient || LastModifiedFromServer> LastModifiedOnClient – RoyM
यह एक और कथन है क्योंकि ईटाग कमजोर हो सकता है, इस मामले में आप एक अर्थात् समकक्ष इकाई प्राप्त कर सकते हैं और फिर आप अंतिम संशोधित शीर्षलेख पर वापस आते हैं। ऐसी स्थिति पर विचार करें जहां एक तस्वीर को फिर से एन्कोड किया जा सकता है और हम कहना चाहते हैं कि मूल और पुन: एन्कोडिंग वही हैं, इस तथ्य के बावजूद कि वे बाइट-समान नहीं हैं। इस मामले में हम अंतिम-संशोधित फ़ॉलबैक के रूप में उपयोग करना चाहते हैं और यही कारण है कि वे दोनों – ParoX