एचटीटीपी रिस्पॉन्स हेडर के लिए सहायता

Apigee Edge दस्तावेज़ देखा जा रहा है.
Apigee X दस्तावेज़ पर जाएं. जानकारी

इस विषय में बताया गया है कि जब Response cache नीति का इस्तेमाल किया जा रहा होता है, तो Edge, एचटीटीपी/1.1 कैश मेमोरी वाले हेडर को कैसे मैनेज करता है. फ़िलहाल, Apigee Edge, बैकएंड टारगेट (ऑरिजिन) सर्वर से मिलने वाले एचटीटीपी/1.1 कैशिंग हेडर और डायरेक्टिव (इस विषय में काम न करने वाली सुविधाओं की सूची में शामिल है) के एक सबसेट के साथ काम करता है.

इसके अलावा, कुछ हेडर के साथ Edge उनके निर्देशों के आधार पर कार्रवाई करता है. कुछ मामलों में, ये एचटीटीपी/1.1 कैश हेडर, Response cache नीति में बताए गए व्यवहार को बदल देते हैं. उदाहरण के लिए, अगर Cache-Control हेडर को बैकएंड सर्वर से दिखाया जाता है, तो हेडर के s-maxage डायरेक्टिव की मदद से, समयसीमा खत्म होने की अन्य सेटिंग को बदला जा सकता है.

हेडर	सहायता
कैश कंट्रोल	बैकएंड ऑरिजिन सर्वर से मिले रिस्पॉन्स पर काम करती है, लेकिन क्लाइंट के अनुरोधों पर नहीं. Edge, डायरेक्टिव के सबसेट के साथ काम करता है.
समयसीमा खत्म होने की तारीख	काम करता है. बदला जा सकता है.
इकाई टैग (ETag)	If-Match और If-None-Match के लिए खास व्यवहार.
अगर बदलाव करने की तारीख है	जीईटी अनुरोधों पर, हेडर को मूल सर्वर को पास किया जाता है, भले ही मान्य कैश एंट्री मौजूद हो.
कोड में बदलने का अनुरोध स्वीकार करें	Edge, आने वाले हेडर के आधार पर, कंप्रेस किए गए या बिना कंप्रेस किए रिस्पॉन्स भेजता है.

कैश-कंट्रोल

Apigee Edge, सिर्फ़ बैकएंड ऑरिजिन सर्वर से मिले रिस्पॉन्स पर Cache-Control हेडर के साथ काम करता है. एचटीटीपी/1.1 स्पेसिफ़िकेशन में, क्लाइंट के अनुरोधों और ऑरिजिन सर्वर के रिस्पॉन्स, दोनों में Cache-Control हेडर इस्तेमाल करने की अनुमति है. ऑरिजिन सर्वर में, Apigee Edge API के प्रॉक्सी में तय किए गए टारगेट एंडपॉइंट और टारगेट सर्वर एपीआई कॉल का इस्तेमाल करके बनाए गए, दोनों तरह के टारगेट एंडपॉइंट शामिल हो सकते हैं.

कैश-कंट्रोल के लिए सहायता से जुड़ी सीमाएं

Apigee Edge, एचटीटीपी/1.1 स्पेसिफ़िकेशन में बताई गई Cache-Control रिस्पॉन्स हेडर क्षमताओं के एक सबसेट के साथ काम करता है. कृपया यहां बताई गई चीज़ों पर ध्यान दें:

• Apigee Edge, ऐसे Cache-Control हेडर के साथ काम नहीं करता है जो इनबाउंड क्लाइंट अनुरोधों के साथ आते हैं.
• Apigee Edge, सिर्फ़ सार्वजनिक कैश मेमोरी के साथ काम करता है. (एचटीटीपी स्पेसिफ़िकेशन के मुताबिक, Cache-Control सार्वजनिक (शेयर किया गया) या निजी (एक उपयोगकर्ता) हो सकता है.
• एचटीटीपी/1.1 स्पेसिफ़िकेशन में, Apigee Edge Cache-Control रिस्पॉन्स डायरेक्टिव के सिर्फ़ एक सबसेट के साथ काम करता है. ज़्यादा जानकारी के लिए, कैश-कंट्रोल के रिस्पॉन्स हेडर डायरेक्टिव के लिए सहायता देखें.

कैश-कंट्रोल के रिस्पॉन्स हेडर निर्देशों के लिए सहायता

Apigee, ऑरिजिन सर्वर से मिलने वाले जवाबों पर एचटीटीपी/1.1 स्पेसिफ़िकेशन के मुताबिक दिए गए सबसेट के निर्देशों के साथ काम करता है. नीचे दी गई टेबल में बताया गया है कि एचटीटीपी कैश-कंट्रोल के रिस्पॉन्स हेडर वाले डायरेक्टिव के लिए, Apigee Edge काम करता है.

यहां दिए गए डायरेक्टिव के बारे में ज़्यादा जानने के लिए, एचटीटीपी/1.1 स्पेसिफ़िकेशन में कैश कंट्रोल देखें.

कैश-कंट्रोल से जुड़ा डायरेक्टिव	Apigee Edge, डायरेक्टिव को कैसे प्रोसेस करता है
cache-extension	मौजूद नहीं.
max-age	अगर आपकी Responseकैश नीति, <UseResponseCacheHeaders> एलिमेंट को true पर सेट करती है, तो रिस्पॉन्स को इस डायरेक्टिव में बताए गए सेकंड की संख्या तक कैश मेमोरी में सेव किया जा सकता है. यह डायरेक्टिव, s-maxage डायरेक्टिव से बदल जाता है और Expires हेडर को बदल देता है. इसे नीति के <ExpirySettings> एलिमेंट से भी बदला जा सकता है. ज़्यादा जानकारी के लिए, रिस्पॉन्स कैश की नीति में जाकर, "कैश मेमोरी में डेटा डालने की समयसीमा सेट करना" और <UseResponseCacheHeaders> देखें.
must-revalidate	मौजूद नहीं. जैसे ही Apigee Edge, कैश मेमोरी में सेव की गई सभी एंट्री को मिटा देता है, वैसे ही उन्हें मिटा दिया जाता है.
no-cache	Edge, ऑरिजिन रिस्पॉन्स को कैश मेमोरी में सेव करता है, लेकिन बाद के किसी भी क्लाइंट के अनुरोध को पूरा करने के लिए इसका इस्तेमाल करने से पहले, इसकी पुष्टि ऑरिजिन सर्वर की मदद से दोबारा करनी होगी. यह नियम यह बताने के लिए कि रिस्पॉन्स को कैश मेमोरी से दिखाया जाना चाहिए, मूल को 304 कोई बदलाव नहीं किया गया रिस्पॉन्स दिखाने की अनुमति देता है. इस तरह, पूरे रिस्पॉन्स को लौटाने के लिए ज़रूरी प्रोसेसिंग सेव हो जाती है. अगर ऑरिजिन सर्वर पूरा जवाब देता है, तो वह मौजूदा कैश एंट्री को बदल देता है. इस डायरेक्टिव के साथ दिए गए फ़ील्ड के किसी भी नाम को अनदेखा कर दिया जाता है.
no-store	मौजूद नहीं.
no-transform	मौजूद नहीं.
private	मौजूद नहीं. यह डायरेक्टिव मिलने पर, ऑरिजिन रिस्पॉन्स को कैश मेमोरी में सेव नहीं किया जाता. किसी भी फ़ील्ड के नाम को अनदेखा कर दिया जाता है.
proxy-revalidate	मौजूद नहीं. जैसे ही Apigee Edge, कैश मेमोरी में सेव की गई सभी एंट्री को मिटा देता है, वैसे ही उन्हें मिटा दिया जाता है.
public	Edge, ऑरिजिन रिस्पॉन्स को कैश मेमोरी में सेव करता है, तब भी जब दूसरे निर्देश कहीं और संकेत करते हैं. एचटीटीपी/1.1 स्पेसिफ़िकेशन के मुताबिक, इस नियम का अपवाद सिर्फ़ तब है, जब रिस्पॉन्स में ऑथराइज़ेशन हेडर शामिल हो.
s-maxage	अगर आपकी Responseकैश नीति, <UseResponseCacheHeaders> एलिमेंट को true पर सेट करती है, तो रिस्पॉन्स को इस डायरेक्टिव में बताए गए सेकंड की संख्या तक कैश मेमोरी में सेव किया जा सकता है. यह डायरेक्टिव, max-age डायरेक्टिव और Expires हेडर को बदल देता है. इसे नीति के <ExpirySettings> एलिमेंट से बदला जा सकता है. ज़्यादा जानकारी के लिए, रिस्पॉन्स कैश की नीति में जाकर, "कैश मेमोरी में डेटा डालने की समयसीमा सेट करना" और <UseResponseCacheHeaders> देखें.

ख़त्म होने की तारीख़

जब Responseकैश नीति में UseResponseCacheHeaders फ़्लैग को true पर सेट किया जाता है, तब Edge Expires हेडर का इस्तेमाल कर सकता है. इससे कैश मेमोरी में सेव की गई एंट्री के लाइव होने का समय (टीटीएल) तय किया जा सकता है. यह हेडर ऐसी तारीख/समय के बारे में बताता है जिसके बाद रिस्पॉन्स की कैश एंट्री को पुरानी माना जाता है. इस हेडर की मदद से सर्वर, सर्वर को सिग्नल भेज सकते हैं. इससे पता चलता है कि टाइम स्टैंप के आधार पर, कैश मेमोरी में सेव की गई वैल्यू कब दिखाई जा सकती है.

Expires हेडर के लिए स्वीकार किए जाने वाले तारीख फ़ॉर्मैट के बारे में एचटीटीपी/1.1 स्पेसिफ़िकेशन में बताया गया है. उदाहरण के लिए:

समाप्ति: गुरुवार, 01 दिसंबर 1994 16:00:00 GMT

एचटीटीपी की तारीख/समय फ़ॉर्मैट के बारे में ज़्यादा जानकारी के लिए, एचटीटीपी/1.1 स्पेसिफ़िकेशन में, तारीख/समय के फ़ॉर्मैट देखें.

Expires हेडर के बारे में ज़्यादा जानकारी के लिए, एचटीटीपी/1.1 स्पेसिफ़िकेशन में, हेडर फ़ील्ड की परिभाषाएं देखें.

ETag

इकाई टैग (ETag) एक आइडेंटिफ़ायर है, जो अनुरोध किए गए संसाधन से जुड़ा होता है. ETag का इस्तेमाल करके, सर्वर यह पता लगा सकता है कि अनुरोध किए गए संसाधन और उससे जुड़े कैश मेमोरी में सेव किए गए संसाधन मेल खाते हैं या नहीं. उदाहरण के लिए, अगर रिस्पॉन्स, मौजूदा कैश मेमोरी से मेल नहीं खाता है, तो सर्वर उसे फिर से कैश मेमोरी में सेव कर सकता है. अगर ETag मेल खाते हैं, तो यह कैश मेमोरी में सेव किए गए रिसॉर्स को दिखा सकता है.

जब टारगेट एंडपॉइंट, ETag की मदद से Edge को वापस जवाब भेजता है, तो Edge, रिस्पॉन्स के साथ ETag को कैश मेमोरी में सेव कर देता है.

इकाई टैग के बारे में ज़्यादा जानने के लिए, एचटीटीपी/1.1 स्पेसिफ़िकेशन में, प्रोटोकॉल पैरामीटर देखें.

अगर-मिलता-जुलता है

If-Match अनुरोध के हेडर के साथ, अगर हेडर में मौजूद ETag, कैश मेमोरी में सेव किए गए ETag से मेल खाता है, तो कैश मेमोरी में सेव की गई इकाई मौजूदा होती है. जीईटी के अलावा, If-Match हेडर के बारे में बताने वाले सभी अनुरोध ऑरिजिन सर्वर को भेजे जाते हैं, ताकि यह पक्का किया जा सके कि ऑरिजिन कैश करने वाली सभी सुविधाओं के पास अनुरोध को प्रोसेस करने का मौका हो.

If-Match के बारे में ज़्यादा जानकारी के लिए, एचटीटीपी/1.1 स्पेसिफ़िकेशन में, हेडर फ़ील्ड की परिभाषाएं देखें.

अगर Edge को किसी ऐसे क्लाइंट से इनबाउंड जीईटी अनुरोध मिलता है जिसमें If-Match हेडर शामिल है, तो:

अगर	इसके बाद
If-Match हेडर में एक या उससे ज़्यादा ETag दिखते हैं	Apigee Edge, दिए गए संसाधन के लिए कैश मेमोरी में सेव की गई ऐसी एंट्री को इकट्ठा करता है जिनकी समयसीमा खत्म नहीं हुई है. साथ ही, कैश मेमोरी में सेव की गई एंट्री पर मौजूद किसी भी मज़बूत ETag की तुलना If-Match हेडर में बताए गए ETag से करता है. अगर कोई मिलान मिलता है, तो कैश एंट्री दिखाई जाती है. अगर ऐसा नहीं है, तो अनुरोध को मूल सर्वर पर भेज दिया जाता है.
If-Match हेडर में "*" लिखा होता है	अनुरोध को ऑरिजिन सर्वर पर भेजा जाता है, ताकि यह पक्का किया जा सके कि ऑरिजिन कैश करने वाली किसी भी सुविधा के पास अनुरोध को प्रोसेस करने का मौका हो
समान अनुरोध यूआरआई वाली कैश एंट्री मिली, लेकिन उसमें सिर्फ़ कमज़ोर ETag हैं	क्लाइंट को वापस भेजे जाने से पहले, ऑरिजिन सर्वर को एंट्री की फिर से पुष्टि करनी होगी
ETag, ऑरिजिन सर्वर से आते हैं.	ETag, क्लाइंट को बिना किसी बदलाव के वापस करता है

अगर-कोई मैच नहीं

अगर हेडर में मौजूद ETag, कैश मेमोरी में सेव किए गए ETag से मेल नहीं खाता है, तो If-None-Match हेडर के साथ, कैश की गई इकाई मौजूदा होती है. इस हेडर वाले जीईटी के अलावा, दूसरे अनुरोध ऑरिजिन सर्वर पर भेज दिए जाते हैं.

अगर Edge को इस हेडर के साथ इनबाउंड जीईटी अनुरोध मिलता है, तो:

अगर	इसके बाद
If-None-Match हेडर में एक या उससे ज़्यादा ETag दिखते हैं	Apigee Edge, तय किए गए यूआरआई के लिए, कैश मेमोरी में सेव की गई ऐसी एंट्री को फिर से हासिल करता है जिनकी समयसीमा खत्म नहीं हुई है. साथ ही, कैश मेमोरी में सेव की गई उन एंट्री पर मौजूद किसी भी मज़बूत ETag की तुलना If-None-Match हेडर में बताए गए ETag से करता है. अगर कोई मिलता-जुलता कोड मिलता है, तो Edge 304 कोई बदलाव नहीं किया गया स्टेटस दिखाता है. अगर कोई मिलता-जुलता नतीजा नहीं मिलता है, तो Edge, अनुरोध को मूल सर्वर को भेज देता है.
If-None-Match हेडर "*" के बारे में बताता है. साथ ही, अनुरोध किए गए यूआरआई के लिए कैश मेमोरी में सेव की गई ऐसी एंट्री मौजूद है जिसकी समयसीमा खत्म नहीं हुई है	Edge 304 बदलाव नहीं किया गया स्थिति देता है
समान अनुरोध यूआरआई वाली कैश एंट्री मिली है, लेकिन उसमें सिर्फ़ कमज़ोर ETag हैं	Edge क्लाइंट को एंट्री लौटाने से पहले, मूल सर्वर को एंट्री की फिर से पुष्टि करनी होगी
Edge को ऑरिजिन सर्वर से ETag मिलता है	ETag, क्लाइंट को बिना किसी बदलाव के वापस करता है

अगर बदलाव किया गया

अगर जीईटी अनुरोध में Apigee Edge को If-Modified-Since हेडर मिलता है, तो इसे ऑरिजिन सर्वर को पास कर दिया जाता है. भले ही, मान्य कैश एंट्री मौजूद हो.

इससे यह पक्का होता है कि किसी ऐसे संसाधन में किए गए अपडेट जो Apigee Edge से नहीं गुज़रे हैं. अगर ऑरिजिन सर्वर एक नई इकाई दिखाता है, तो Edge मौजूदा कैश एंट्री को नई वैल्यू से बदल देता है. अगर सर्वर, 'बदलाव नहीं किया गया है' स्टेटस दिखाता है, तो Edge रिस्पॉन्स वैल्यू दिखाता है. ऐसा तब होता है, जब कैश मेमोरी में सेव किए गए रिस्पॉन्स के Last-Modified हेडर से यह पता चलता हो कि कोई बदलाव नहीं किया गया है.

कोड में बदलने का अनुरोध स्वीकार करें

जब किसी इनकमिंग अनुरोध में gzip, deflate या compress की वैल्यू के साथ Accept-Encoding हेडर शामिल होता है, तो ऑरिजिन सर्वर कंप्रेस किए गए डेटा के साथ जवाब देता है. जब बाद के अनुरोध Accept-Encoding हेडर के बिना आते हैं, तो वे बिना कंप्रेस किए गए जवाब की उम्मीद करते हैं. Apigee की रिस्पॉन्स को कैश मेमोरी में सेव करने की सुविधा, आने वाले हेडर के आधार पर, कंप्रेस किए गए और कंप्रेस नहीं किए गए, दोनों तरह के जवाब भेज सकती है. इसके लिए, मूल सर्वर पर वापस नहीं जाना होगा.

कैश मेमोरी में सेव किए गए हर आइटम के लिए, पासकोड को ज़्यादा काम का बनाने के लिए, कैश मेमोरी में सेव की गई कुंजियों में 'हेडर की वैल्यू स्वीकार करें' जोड़ी जा सकती है. ज़्यादा जानकारी के लिए, रिस्पॉन्स कैश से जुड़ी नीति में "कैश कुंजी कॉन्फ़िगर करना" देखें.