पूर्वता क्या है: ETag या अंतिम-संशोधित HTTP हेडर?

Question

बाद के दो अनुरोधों के लिए, ब्राउज़रों द्वारा निम्नलिखित में से किस दो हेडर को अधिक वजन दिया गया है, उनमें से एक को बदलना चाहिए: ईटैग या अंतिम-संशोधित?

Answer 1

RFC 2616 खंड 13.3.4 के अनुसार , एक HTTP 1.1 क्लाइंट किसी भी कैश-सशर्त अनुरोधों में ETag का उपयोग करना चाहिए, और यदि ETag और अंतिम संशोधित दोनों मौजूद हैं, तो यह दोनों का उपयोग करना चाहिए। ETag हेडर एक मजबूत सत्यापनकर्ता माना जाता है (अनुभाग 13.3.3 देखें), जब तक कि सर्वर द्वारा स्पष्ट रूप से कमजोर घोषित नहीं किया जाता है, जबकि अंतिम संशोधित हेडर को कमजोर माना जाता है जब तक कि इसके और दिनांक हेडर के बीच कम से कम एक मिनट का अंतर मौजूद न हो। ध्यान दें, हालांकि सर्वर को भेजने की आवश्यकता नहीं है (लेकिन यदि यह हो सकता है), तो इसे भेजना होगा।

ध्यान दें कि क्लाइंट हेडर को यह देखने के लिए नहीं देखता है कि क्या वे बदल गए हैं; यह बस आँख बंद करके अगली सशर्त अनुरोध में उनका उपयोग करता है; यह सर्वर पर निर्भर है कि वह अनुरोधित सामग्री भेज सकता है या कोई 304 संशोधित प्रतिक्रिया नहीं। यदि सर्वर केवल एक भेजता है, तो क्लाइंट उस अकेले का उपयोग करेगा (हालांकि, केवल मजबूत सत्यापनकर्ता एक रेंज अनुरोध के लिए उपयोगी हैं)। बेशक, यह मध्यवर्ती कैश के विवेक पर भी है (जब तक कि उन्हें कैश कंट्रोल निर्देशों के माध्यम से कैशिंग से रोका नहीं गया है) और सर्वर के रूप में वे हेडर पर कैसे कार्य करेंगे; RFC बताता है कि वे जरूरी नहीं कि यदि कोई विधायक असंगत हैं तो 304 नॉट मॉडिफ़ाइड लौटा दें, लेकिन चूंकि हेडर मान सर्वर द्वारा जेनरेट किए जाते हैं, इसलिए इसमें काफी कुछ है।

व्यवहार में, मैंने देखा है कि क्रोम, फायरफॉक्स और IE 7+ सभी उपलब्ध होने पर दोनों हेडर भेजते हैं। मैंने संशोधित हेडर भेजते समय व्यवहार का भी परीक्षण किया था, जो मुझे पहले से ही आरएफसी में जानकारी से संदेह था। यदि मैंने पृष्ठ को रिफ्रेश किया था या चार बार वर्तमान प्रक्रिया द्वारा अनुरोध किया गया था, तो मैंने जिन चार ग्राहकों का परीक्षण किया था, उन्होंने केवल सशर्त अनुरोध भेजे थे।

Comments

महान जवाब, थॉमस। आधिकारिक युक्ति प्रदान करने और वर्तमान ब्राउज़र कार्यान्वयन पर चर्चा करने के लिए धन्यवाद।

— dthrasher

अनुभाग 14.26 से उद्धृत करते हुए, सर्वर अनुरोधित विधि का प्रदर्शन नहीं करता है, जब तक कि ऐसा करने की आवश्यकता न हो, क्योंकि संसाधन का संशोधन दिनांक उस मेल से मेल नहीं खाता है, जो अनुरोध में एक इफ-संशोधित-हेडर फ़ील्ड में आपूर्ति की गई है। इफ-मॉडिफ़ाइड-चूंकि पूर्वता लेता है।

— विकारी

Answer 2

क्या यह "ओआर" अभिव्यक्ति की तरह नहीं है। छद्म कोड में:

if ETagFromServer != ETagOnClient || LastModifiedFromServer != LastModifiedOnClient
   GetFromServer
else
   GetFromCache

Comments

मुझे लगता है कि अंतिम संशोधित टाइमस्टैम्प की तुलना अलग तरीके से की जानी चाहिए, जैसे: यदि ETagFromServer! = ETagOnClient ||

— LastModifiedFromServer

यह एक AND कथन है क्योंकि ETag कमजोर हो सकता है जिस स्थिति में आपके पास एक शब्दार्थ समतुल्य इकाई हो सकती है और फिर आप अंतिम-संशोधित शीर्ष लेख पर वापस आते हैं। ऐसी स्थिति पर विचार करें जहां एक तस्वीर को फिर से एन्कोड किया जा सकता है और हम कहना चाहते हैं कि मूल और पुनः एन्कोडिंग इस तथ्य के बावजूद समान हैं कि वे बाइट-समान नहीं हैं। इस मामले में हम अंतिम बदलाव का उपयोग

— कमबैक के

Answer 3

=! सही तुलना ऑपरेटर है। क्लाइंट को सर्वर से प्राप्त शाब्दिक स्ट्रिंग को रखने की आवश्यकता होती है, क्योंकि रूपांतरण छोटे अंतर बना सकते हैं। आप यह नहीं मान सकते कि 'नया बेहतर है'।

क्यों? उस मामले पर विचार करें जहां सर्वर ऑपरेटर किसी संसाधन के खराब संस्करण को बदल देता है। उलटा संस्करण OLDER है - लेकिन सही है।

क्लाइंट को वर्तमान में सर्वर द्वारा प्रस्तुत संस्करण का उपयोग करना चाहिए; यह केवल कैश्ड संस्करण का उपयोग कर सकता है यदि यह समान है। इस प्रकार सर्वर को समानता की जांच करनी चाहिए, न कि 'नए' की।