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कैश नीति, यह डायरेक्टिव, |
must-revalidate |
मौजूद नहीं. जैसे ही Apigee Edge, कैश मेमोरी में सेव की गई सभी एंट्री को मिटा देता है, वैसे ही उन्हें मिटा दिया जाता है. |
no-cache |
Edge, ऑरिजिन रिस्पॉन्स को कैश मेमोरी में सेव करता है, लेकिन बाद के किसी भी क्लाइंट के अनुरोध को पूरा करने के लिए इसका इस्तेमाल करने से पहले, इसकी पुष्टि ऑरिजिन सर्वर की मदद से दोबारा करनी होगी. यह नियम यह बताने के लिए कि रिस्पॉन्स को कैश मेमोरी से दिखाया जाना चाहिए, मूल को 304 कोई बदलाव नहीं किया गया रिस्पॉन्स दिखाने की अनुमति देता है. इस तरह, पूरे रिस्पॉन्स को लौटाने के लिए ज़रूरी प्रोसेसिंग सेव हो जाती है. अगर ऑरिजिन सर्वर पूरा जवाब देता है, तो वह मौजूदा कैश एंट्री को बदल देता है. इस डायरेक्टिव के साथ दिए गए फ़ील्ड के किसी भी नाम को अनदेखा कर दिया जाता है. |
no-store |
मौजूद नहीं. |
no-transform |
मौजूद नहीं. |
private |
मौजूद नहीं. यह डायरेक्टिव मिलने पर, ऑरिजिन रिस्पॉन्स को कैश मेमोरी में सेव नहीं किया जाता. किसी भी फ़ील्ड के नाम को अनदेखा कर दिया जाता है. |
proxy-revalidate |
मौजूद नहीं. जैसे ही Apigee Edge, कैश मेमोरी में सेव की गई सभी एंट्री को मिटा देता है, वैसे ही उन्हें मिटा दिया जाता है. |
public |
Edge, ऑरिजिन रिस्पॉन्स को कैश मेमोरी में सेव करता है, तब भी जब दूसरे निर्देश कहीं और संकेत करते हैं. एचटीटीपी/1.1 स्पेसिफ़िकेशन के मुताबिक, इस नियम का अपवाद सिर्फ़ तब है, जब रिस्पॉन्स में ऑथराइज़ेशन हेडर शामिल हो. |
s-maxage |
अगर आपकी Responseकैश नीति, यह डायरेक्टिव, |
ख़त्म होने की तारीख़
जब 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 दिखते हैं |
|
If-Match हेडर में "*" लिखा होता है |
अनुरोध को ऑरिजिन सर्वर पर भेजा जाता है, ताकि यह पक्का किया जा सके कि ऑरिजिन कैश करने वाली किसी भी सुविधा के पास अनुरोध को प्रोसेस करने का मौका हो |
समान अनुरोध यूआरआई वाली कैश एंट्री मिली, लेकिन उसमें सिर्फ़ कमज़ोर ETag हैं | क्लाइंट को वापस भेजे जाने से पहले, ऑरिजिन सर्वर को एंट्री की फिर से पुष्टि करनी होगी |
ETag, ऑरिजिन सर्वर से आते हैं. | ETag, क्लाइंट को बिना किसी बदलाव के वापस करता है |
अगर-कोई मैच नहीं
अगर हेडर में मौजूद ETag, कैश मेमोरी में सेव किए गए ETag से मेल नहीं खाता है, तो If-None-Match
हेडर के साथ, कैश की गई इकाई मौजूदा होती है. इस हेडर वाले जीईटी के अलावा,
दूसरे अनुरोध ऑरिजिन सर्वर पर भेज दिए जाते हैं.
अगर Edge को इस हेडर के साथ इनबाउंड जीईटी अनुरोध मिलता है, तो:
अगर | इसके बाद |
---|---|
If-None-Match हेडर में एक या उससे ज़्यादा ETag दिखते हैं |
|
|
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 की रिस्पॉन्स को कैश मेमोरी में सेव करने की सुविधा,
आने वाले हेडर के आधार पर,
कंप्रेस किए गए और कंप्रेस नहीं किए गए, दोनों तरह के जवाब भेज सकती है. इसके लिए,
मूल सर्वर पर वापस नहीं जाना होगा.
कैश मेमोरी में सेव किए गए हर आइटम के लिए, पासकोड को ज़्यादा काम का बनाने के लिए, कैश मेमोरी में सेव की गई कुंजियों में 'हेडर की वैल्यू स्वीकार करें' जोड़ी जा सकती है. ज़्यादा जानकारी के लिए, रिस्पॉन्स कैश से जुड़ी नीति में "कैश कुंजी कॉन्फ़िगर करना" देखें.