"वेरी: स्वीकार करें" HTTP शीर्षलेख का कार्य क्या है?

Question

मैं गतिशील वेब पेज उत्पन्न करने के लिए PHP का उपयोग करता हूं। जैसा कि निम्नलिखित ट्यूटोरियल पर बताया गया है (नीचे लिंक देखें), एक्सएचटीएमएल दस्तावेज़ों का एमआईएमई प्रकार "एप्लिकेशन/एक्सएचटीएमएल + एक्सएमएल" होना चाहिए जब $ _SERVER ['HTTP_ACCEPT'] इसे अनुमति देता है। चूंकि आप एक ही पृष्ठ को 2 अलग-अलग MIMEs ("एप्लिकेशन/xhtml + xml" और "text/html") के साथ सेवा कर सकते हैं, इसलिए आपको "Vary" HTTP शीर्षलेख "स्वीकार करें" पर सेट करना चाहिए। यह प्रॉक्सी पर कैश की मदद करेगा।

लिंक: हैडर ('वैरी: स्वीकार करें') http://keystonewebsites.com/articles/mime_type.php

अब मैं नहीं के निहितार्थ का यकीन है; मैं वास्तव में क्या के बारे में सुनिश्चित नहीं हूँ 'Vary: Accept' ठीक करना होगा ...

केवल स्पष्टीकरण मैंने पाया है:

Content-Type हैडर के बाद, एक भिन्न हैडर भेज दिया जाता है (यदि मैं इसे सही ढंग से समझता हूं) इंटरमीडिएट कैश, प्रॉक्सी सर्वर की तरह बताएं, सामग्री दस्तावेज़ का प्रकार क्लाइंट की क्षमताओं पर निर्भर करता है जो दस्तावेज़ का अनुरोध करता है। http://www.456bereastreet.com/archive/200408/content_negotiation/

किसी को भी मुझे (कि मूल्य साथ ) इस हेडर के एक 'असली' स्पष्टीकरण दे सकते हैं। मुझे लगता है मैं जैसी चीजों को समझने लगता है: से बदलते हैं: Accept-Encoding जहां प्रॉक्सी पर कैश पेज की एन्कोडिंग की सेवा के आधार पर किया जा सकता है, लेकिन मुझे समझ नहीं आता: Vary: Accept

Answer 1

• cache-control एक HTTP सर्वर के लिए शीर्षलेख एक कैशिंग प्रॉक्सी को प्रतिक्रिया की "ताजगी" बताने के लिए प्राथमिक तंत्र है। (यानी, कैश में प्रतिक्रिया को स्टोर करने के लिए कितना/लंबा)

• कुछ स्थितियों में, cache-control निर्देश अपर्याप्त हैं। HTTP कार्य समूह से एक चर्चा here, संग्रहित एक पृष्ठ का वर्णन करती है जो केवल भाषा के साथ बदलती है। यह भिन्न हेडर के लिए सही उपयोग केस है, लेकिन संदर्भ हमारी चर्चा के लिए मूल्यवान है।

Vary उन मामलों में जहाँ यह निराशाजनक या जरूरत से ज्यादा एक के लिए जटिल है के लिए ही है: कि पृष्ठ से (हालांकि मेरा मानना ​​है कि वैरी हैडर उस मामले में समस्या का समाधान होगा, वहाँ एक बेहतर तरीका है।) सर्वर क्या करेगा यह दोहराने के लिए प्रॉक्सी।

• RFC2616 "Header-Field Definitions" सर्वर परिप्रेक्ष्य, RFC2616 "Caching Negotiated Responses" एक कैशिंग प्रॉक्सी नजरिए से से हैडर उपयोग का वर्णन। इसका उद्देश्य HTTP अनुरोध शीर्षकों का एक सेट निर्दिष्ट करना है जो अनुरोध की विशिष्टता निर्धारित करते हैं।

एक काल्पनिक उदाहरण:

आपका HTTP सर्वर एक बड़ी लैंडिंग पृष्ठ है। आपके पास एक ही यूआरएल के साथ दो अलग-अलग पेज हैं, भले ही उपयोगकर्ता पहले वहां रहा हो। कुकीज़ के आधार पर आप अनुरोधों और उपयोगकर्ता की "विज़िट गिनती" के बीच अंतर करते हैं।लेकिन - चूंकि आपके सर्वर का लैंडिंग पृष्ठ इतना बड़ा है, इसलिए यदि आप संभव हो तो प्रतिक्रिया को कैश करने के लिए मध्यस्थ प्रॉक्सी चाहते हैं।

यूआरएल, अंतिम-संशोधित और कैश-कंट्रोल हेडर इस अंतर्दृष्टि को कैशिंग प्रॉक्सी को अपर्याप्त करने के लिए अपर्याप्त हैं, लेकिन यदि आप Vary: Cookie जोड़ते हैं, तो कैश इंजन कुकी कैडर को अपने कैशिंग निर्णयों में जोड़ देगा।

अंत में, छोटे यातायात, गतिशील वेबसाइटों के लिए - मुझे हमेशा सरल Cache-Control: no-cache, no-store और Pragma: no-cache पर्याप्त मिला है।

संपादित करें - अपने प्रश्न का अधिक सटीक उत्तर देने के लिए: HTTP अनुरोध हेडर 'स्वीकार करें' सामग्री-प्रकार को परिभाषित करता है जो क्लाइंट प्रक्रिया कर सकता है। यदि आपके पास एक ही यूआरएल पर एक ही सामग्री की दो प्रतियां हैं, तो केवल सामग्री-प्रकार में भिन्न होती है, फिर Vary: Accept का उपयोग करना उचित हो सकता है।

अद्यतन 11 सितं, 12:

मैं एक जोड़ी लिंक है कि टिप्पणी में दिखाई दिया के बाद से इस टिप्पणी को मूल रूप से तैनात किया गया था शामिल कर रहा हूँ। वे वेरी के साथ असली दुनिया के उदाहरणों (और समस्याओं) के लिए उत्कृष्ट संसाधन हैं: स्वीकार करें; अगर आप इस जवाब को पढ़ रहे हैं तो आपको उन लिंक को भी पढ़ने की जरूरत है।

बकाया एरिकलो से पहले, वेरी हेडर के साथ इंटरनेट एक्सप्लोरर के व्यवहार पर और डेवलपर्स को प्रस्तुत कुछ चुनौतियों पर: Vary Header Prevents Caching in IE। संक्षेप में, आईई (पूर्व आईई 9) वेरी हेडर का उपयोग करने वाली किसी भी सामग्री को कैश नहीं करता है क्योंकि अनुरोध कैश में HTTP अनुरोध शीर्षलेख शामिल नहीं हैं। एरिकलो (असली दुनिया में एरिक लॉरेंस) आईई टीम पर एक प्रोग्राम मैनेजर है।

दूसरा एरान मेडन से है, और क्रोम में वेरी से संबंधित अप्रत्याशित व्यवहार की चल रही चर्चा है: Backing doesn't handle Vary header correctly। यह आईई के व्यवहार से संबंधित है, सिवाय इसके कि क्रोम देवों ने एक अलग दृष्टिकोण लिया - हालांकि यह एक जानबूझकर विकल्प नहीं प्रतीत होता है।

Answer 2

Vary: Accept बस कहता है कि प्रतिक्रिया Accept शीर्षलेख के आधार पर उत्पन्न हुई थी। एक अलग Accept शीर्षलेख के साथ एक अनुरोध एक अलग प्रतिक्रिया प्राप्त हो सकता है।

(आप कि जुड़ा हुआ PHP कोड $HTTP_ACCEPT पर लग रहा है देख सकते हैं। यही कारण है कि Accept अनुरोध हेडर का मूल्य है।)

HTTP कैश करने के लिए

, इसका मतलब है कि प्रतिक्रिया अतिरिक्त देखभाल के साथ कैश्ड किया जाना चाहिए। यह केवल के साथ उसी Accept शीर्षलेख के साथ अनुरोध के लिए एक वैध मिलान होने जा रहा है।

अब यह केवल तभी महत्वपूर्ण है जब पृष्ठ पहली जगह कैशबल हो। डिफ़ॉल्ट रूप से, PHP पृष्ठ नहीं हैं। एक PHP पृष्ठ आउटपुट को कुछ हेडर (Expires, उदाहरण के लिए) भेजकर कैश करने योग्य के रूप में चिह्नित कर सकता है। लेकिन क्या और कैसे करना एक अलग सवाल है।

Answer 3

यह google webmaster video HTTP Vary शीर्षलेख के बारे में बहुत अच्छी व्याख्या है।

Answer 4

वास्तव में जल्द ही (और पहले से ही क्रोम में) आने वाली नई सुविधाओं की एक बड़ी संख्या है जो Vary शीर्षलेख अत्यंत उपयोगी बनाती है। उदाहरण के लिए, Client Hinting पर विचार करें।

• छवि चौड़ाई
• व्यूपोर्ट चौड़ाई
• एन्कोडिंग का प्रकार ब्राउज़र द्वारा समर्थित (लगता है WebP): जब छवियों के संबंध में प्रयोग, उदाहरण के लिए, ग्राहक हिंट इस तरह के आधार पर छवियों के रूप में संसाधनों को अधिकतम करने के लिए एक सर्वर की अनुमति देता है
• डाउनलिंक (अनिवार्य रूप से नेटवर्क की गति)

तो एक सर्वर जो उन सुविधाओं का समर्थन करता Vary हैडर स्थापित करेगा संकेत मिलता है कि।

क्रोम प्रत्येक अनुरोध के लिए Vary शीर्षलेख के हिस्से के रूप में "छवि/वेबपी" सेट करके वेबपी समर्थन का विज्ञापन करता है। तो यदि कोई ब्राउज़र इसका समर्थन करता है तो एक सर्वर वेबप के रूप में एक छवि को फिर से लिख सकता है, इसलिए प्रॉक्सी को हेडर की जांच करने की आवश्यकता होगी ताकि वेबपी छवि कैश न हो और फिर उसे उस ब्राउज़र पर सेवा दें जो वेबप का समर्थन नहीं करता है। जाहिर है, अगर आपका सर्वर ऐसा नहीं करता है, तो इससे कोई फर्क नहीं पड़ता। तो के बाद से सर्वर की प्रतिक्रिया Accept अनुरोध हेडर पर बदलता रहता है, प्रतिक्रिया को शामिल करना चाहिए कि इतनी के रूप में प्रॉक्सी भ्रमित करने के लिए नहीं:

Vary: Accept 

एक और उदाहरण छवि चौड़ाई हो सकता है। एक मोबाइल ब्राउज़र पर Width हेडर एक प्रतिक्रियाशील छवि के लिए काफी छोटा हो सकता है, यदि डेस्कटॉप ब्राउज़र से देखा गया तो इसकी तुलना में यह क्या होगा। तो उस मामले में WidthVary हेडर में जोड़ा जाएगा, प्रॉक्सी के लिए छोटे मोबाइल संस्करण को कैश नहीं करने और डेस्कटॉप ब्राउज़र पर इसकी सेवा करने के लिए हेडर आवश्यक है, या इसके विपरीत। उस मामले में, शीर्ष लेख शामिल हो सकता है:

Vary: Accept, Width 

या केस है जो सर्वर क्लाइंट चश्मा इशारा के सभी समर्थित में, शीर्ष लेख की तरह कुछ होगा:

Vary: Accept, DPR, Width, Save-Data, Downlink