responseCache की नीति

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

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

आपका एपीआई जिस बैकएंड डेटा का इस्तेमाल करता है उसे समय-समय पर अपडेट करने पर, आपको Response cache सबसे ज़्यादा काम का लग सकता है. उदाहरण के लिए, मान लें कि आपके पास एक ऐसा एपीआई है जो सिर्फ़ हर दस मिनट में रीफ़्रेश होने वाली, मौसम की रिपोर्ट का डेटा दिखाता है. रीफ़्रेश के बीच कैश मेमोरी में सेव किए गए रिस्पॉन्स दिखाने के लिए, Responsecache का इस्तेमाल करके, बैकएंड तक पहुंचने वाले अनुरोधों की संख्या कम की जा सकती है. इससे, नेटवर्क के इधर-उधर जाने की संख्या भी कम हो जाती है.

सामान्य मकसद के लिए, कुछ समय के लिए कैश मेमोरी में सेव करना, कैश मेमोरी से जुड़ी नीति का इस्तेमाल करने के बारे में सोचें. इस नीति का इस्तेमाल लुकअप कैश नीति (कैश मेमोरी में सेव की गई एंट्री को पढ़ने के लिए) और कैश मेमोरी को अमान्य करने से जुड़ी नीति (एंट्री अमान्य करने के लिए) के साथ किया जाता है.

सैंपल

http://{org_name}-test.apigee.net/weather/forecastrss?w=23424778

<ResponseCache name="ResponseCache">
    <CacheKey>
        <KeyFragment ref="request.queryparam.w" />
    </CacheKey>
    <ExpirySettings>
        <TimeoutInSeconds>600</TimeoutInSeconds>
    </ExpirySettings>
</ResponseCache>

http://{org_name}-test.apigee.net/weather/forecastrss?w=23424778

'http://{org_name}-test.apigee.net/weather/forecastrss?w=23424778' -H "bypass-cache:true"

<ResponseCache name="ResponseCache">
    <CacheKey>
        <KeyFragment ref="request.queryparam.w" />
    </CacheKey>
    <!-- Explicitly refresh the cached response -->
    <SkipCacheLookup>request.header.bypass-cache = "true"</SkipCacheLookup>
    <ExpirySettings>
        <TimeoutInSeconds>600</TimeoutInSeconds>
    </ExpirySettings>
</ResponseCache>

एलिमेंट का रेफ़रंस

एलिमेंट रेफ़रंस, नीति के एलिमेंट और एट्रिब्यूट के बारे में बताता है.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ResponseCache async="false" continueOnError="false" enabled="true" name="Response-Cache-1">
    <DisplayName>Response Cache 1</DisplayName>
    <Properties/>
    <CacheKey>
        <Prefix/>
        <KeyFragment ref="request.uri" />
    </CacheKey>
    <Scope>Exclusive</Scope>
    <ExpirySettings>
        <ExpiryDate/>
        <TimeOfDay/>
        <TimeoutInSeconds ref="flow.variable.here">300</TimeoutInSeconds>
    </ExpirySettings>
    <CacheResource>cache_to_use</CacheResource>
    <CacheLookupTimeoutInSeconds/>
    <ExcludeErrorResponse/>
    <SkipCacheLookup/>
    <SkipCachePopulation/>
    <UseAcceptHeader/>
    <UseResponseCacheHeaders/>
</ResponseCache>

<Responsecache> एट्रिब्यूट

<ResponseCache async="false" continueOnError="false" enabled="true" name="Response-Cache-1">

इस टेबल में उन एट्रिब्यूट के बारे में बताया गया है जो नीति के सभी पैरंट एलिमेंट के लिए एक जैसे होते हैं:

<DisplayName> एलिमेंट

मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) प्रॉक्सी एडिटर में, आम भाषा के अलग नाम से नीति को लेबल करने के लिए, name एट्रिब्यूट का इस्तेमाल करें.

<DisplayName>Policy Display Name</DisplayName>

<cacheKey> एलिमेंट

यह नीति कैश में स्टोर किए गए डेटा के किसी हिस्से के लिए यूनीक पॉइंटर कॉन्फ़िगर करती है.

कैश कुंजी का साइज़ 2 केबी तक सीमित हो सकता है.

<CacheKey>
    <Prefix>string</Prefix>
    <KeyFragment ref="variable_name" />
    <KeyFragment>literal_string</KeyFragment>
</CacheKey>

<CacheKey>, कैश मेमोरी में सेव किए गए डेटा के हर हिस्से का नाम बनाता है. कुंजी को अक्सर इकाई हेडर या क्वेरी पैरामीटर के मान का इस्तेमाल करके सेट किया जाता है. उन मामलों में, आपके पास एलिमेंट की ref एट्रिब्यूट की वैल्यू के तौर पर, की वैल्यू वाले वैरिएबल को तय किया जाएगा.

रनटाइम पर, <KeyFragment> वैल्यू को <Scope> एलिमेंट वैल्यू या <Prefix> वैल्यू से पहले जोड़ा जाता है. उदाहरण के लिए, यहां दिए गए नतीजे UserToken__apiAccessToken__<value_of_client_id> की कैश कुंजी बनती हैं:

<CacheKey>
    <Prefix>UserToken</Prefix>
    <KeyFragment>apiAccessToken</KeyFragment>
    <KeyFragment ref="request.queryparam.client_id" />
</CacheKey>

<CacheKey> एलिमेंट का इस्तेमाल <Prefix> और <Scope> के साथ किया जाता है. ज़्यादा जानकारी के लिए, कैश कुंजी के साथ काम करना लेख पढ़ें.

< cachelookupTimeoutInSeconds> एलिमेंट

यह नीति सेकंड की वह संख्या तय करती है जिसके बाद, कैश मेमोरी की जांच नहीं होने पर उसे कैश मेमोरी में सेव नहीं माना जाएगा. अगर ऐसा होता है, तो फ़्लो, कैश मेमोरी में सेव किए गए डेटा को हटाने की प्रोसेस के पाथ पर फिर से शुरू हो जाता है.

<CacheLookupTimeoutInSeconds>30</CacheLookupTimeoutInSeconds>

<cacheResource> एलिमेंट

इस नीति की मदद से, यह तय किया जाता है कि मैसेज किस कैश मेमोरी में सेव किए जाएं. शामिल की गई कैश मेमोरी का इस्तेमाल करने के लिए, इस एलिमेंट का इस्तेमाल न करें. अगर आपको कैश मेमोरी में मौजूद एंट्री को एडमिन के तौर पर हटाना है, तो आपको नाम के साथ cacheResource तय करना होगा. इस बारे में ज़्यादा जानकारी के लिए, कैश मेमोरी देखें.

<CacheResource>cache_to_use</CacheResource>

कैश मेमोरी कॉन्फ़िगर करने के बारे में ज़्यादा जानने के लिए, एनवायरमेंट कैश बनाना और उसमें बदलाव करना लेख पढ़ें.

<cacheKey>/<Keyफ़्रैगमेंट> एलिमेंट

इस नीति से वह वैल्यू तय की जाती है जिसे कैश कुंजी में शामिल किया जाना चाहिए. इससे कैश मेमोरी में सेव किए गए रिस्पॉन्स से मेल खाने वाले अनुरोधों के लिए एक नेमस्पेस बनाया जाता है.

<KeyFragment ref="variable_name"/>
<KeyFragment>literal_string</KeyFragment>

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

<KeyFragment>apiAccessToken</KeyFragment>
<KeyFragment ref="request.queryparam.client_id" />

<KeyFragment> एलिमेंट का इस्तेमाल <Prefix> और <Scope> के साथ किया जाता है. ज़्यादा जानकारी के लिए, कैश कुंजी के साथ काम करना लेख पढ़ें.

एट्रिब्यूट

<cacheKey>/<प्रीफ़िक्स> एलिमेंट

इससे पता चलता है कि वैल्यू को कैश कुंजी प्रीफ़िक्स के तौर पर इस्तेमाल करना है.

<Prefix>prefix_string</Prefix>

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

<Prefix> एलिमेंट का इस्तेमाल <CacheKey> और <Scope> के साथ किया जाता है. ज़्यादा जानकारी के लिए, कैश कुंजी के साथ काम करना लेख पढ़ें.

<ExcludeErrorResponse> एलिमेंट

फ़िलहाल, यह नीति डिफ़ॉल्ट रूप से, एचटीटीपी रिस्पॉन्स को किसी भी संभावित स्टेटस कोड के साथ कैश मेमोरी में सेव करती है. इसका मतलब है कि कामयाबी और गड़बड़ी के रिस्पॉन्स, दोनों को कैश मेमोरी में सेव किया जाता है. उदाहरण के लिए, 2xx और 3xx स्टेटस कोड वाले जवाबों को डिफ़ॉल्ट रूप से कैश मेमोरी में सेव किया जाता है.

अगर आपको एचटीटीपी गड़बड़ी के स्टेटस कोड वाले टारगेट रिस्पॉन्स को कैश मेमोरी में सेव नहीं करना है, तो इस एलिमेंट को true पर सेट करें. अगर एलिमेंट सही है, तो सिर्फ़ 200 से 205 के स्टेटस कोड वाले रिस्पॉन्स को कैश मेमोरी में सेव किया जाएगा. सिर्फ़ इन्हीं एचटीटीपी स्टेटस कोड को Edge है, जिन्हें "सक्सेस" कोड के तौर पर गिना जाता है. साथ ही, इस असोसिएशन को बदला नहीं जा सकता.

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

ध्यान दें: आने वाले समय की रिलीज़ में (तय किया जाना बाकी है), इस एलिमेंट की डिफ़ॉल्ट सेटिंग सही में बदल जाएगी. ज़्यादा जानकारी के लिए, Apigee के रिलीज़ नोट्स देखें.

<ExcludeErrorResponse>true</ExcludeErrorResponse>

<ExpirySettings> एलिमेंट

यह तय करता है कि कैश एंट्री कब खत्म होनी चाहिए. मौजूद होने पर, <TimeoutInSeconds> <TimeOfDay> और <ExpiryDate>, दोनों को बदल देता है.

<ExpirySettings>
  <TimeOfDay ref="time_variable">expiration_time</TimeOfDay>
  <TimeoutInSeconds ref="duration_variable">seconds_until_expiration</TimeoutInSeconds>
  <ExpiryDate ref="date_variable">expiration_date</ExpiryDate>
</ExpirySettings>

<ExpirySettings>/<ExpiryDate> एलिमेंट

यह नीति वह तारीख बताती है जब कैश एंट्री की समयसीमा खत्म हो जानी चाहिए. mm-dd-yyyy फ़ॉर्म का इस्तेमाल करें. मौजूद होने पर, इस एलिमेंट का सिबलिंग, <TimeoutInSeconds>, <ExpiryDate> को बदल देता है.

<ExpirySettings>
    <ExpiryDate ref="{date_variable}">expiration_date</ExpiryDate>
</ExpirySettings>

एट्रिब्यूट

<ExpiryDate ref="" />

<ExpirySettings>/<TimeOfDay> एलिमेंट

दिन का वह समय जब कैश एंट्री की समयसीमा खत्म हो जानी चाहिए. hh:mm:ss फ़ॉर्म का इस्तेमाल करें . मौजूद होने पर, इस एलिमेंट का सिबलिंग, <TimeoutInSeconds>, <TimeOfDay> को बदल देता है.

HH:mm:ss फ़ॉर्मैट में दिन का समय डालें. यहां HH, 24 घंटे की घड़ी के समय को दिखाता है. उदाहरण के लिए, दोपहर 2:30 बजे के लिए 14:30:00.

कोड कहां चल रहा है, उसके हिसाब से डिफ़ॉल्ट स्थान-भाषा और टाइम ज़ोन अलग-अलग होंगे. कोड को कॉन्फ़िगर करते समय, इसका पता नहीं लगाया जा सकता. अपनी स्थान-भाषा को कॉन्फ़िगर करने के बारे में जानकारी पाने के लिए, एनवायरमेंट कैश बनाना और उसमें बदलाव करना देखें.

<ExpirySettings>
    <TimeOfDay ref="time_variable">expiration_time</TimeOfDay>
</ExpirySettings>

एट्रिब्यूट

<ExpirySettings>/<TimeoutInSec> एलिमेंट

सेकंड की वह संख्या जिसके बाद कैश एंट्री खत्म होनी चाहिए.

<ExpirySettings>/<TimeoutInSeconds> एलिमेंट

सेकंड की वह संख्या जिसके बाद कैश एंट्री खत्म होनी चाहिए. मौजूद होने पर, यह एलिमेंट अपने सिबलिंग, <TimeOfDay>, और <ExpiryDate> को बदल देता है.

<ExpirySettings>
    <TimeoutInSeconds ref="duration_variable">seconds_until_expiration</TimeoutInSeconds>
</ExpirySettings>

ध्यान दें: अगर रेफ़रर को duration_variable से कोई वैल्यू नहीं मिलती है, तो डिफ़ॉल्ट टाइम आउट वैल्यू दें.

एट्रिब्यूट

<Scope> एलिमेंट

जब <CacheKey> एलिमेंट में <Prefix> एलिमेंट नहीं दिया जाता है, तब कैश कुंजी के लिए प्रीफ़िक्स बनाने के लिए इस्तेमाल की जाने वाली गिनती.

<Scope>scope_enumeration</Scope>

<Scope> सेटिंग एक कैश कुंजी तय करती है, जिसे <Scope> वैल्यू के हिसाब से पहले जोड़ा जाता है. उदाहरण के लिए, जब स्कोप Exclusive पर सेट किया जाता है, तो कैश कुंजी इस तरह से दिखेगी: orgName__envName__apiProxyName__deployedRevisionNumber__proxy|TargetName__ [ orgName__envName__apiProxyName__deployedRevisionNumber__proxy|TargetName__ ].

अगर <CacheKey> में <Prefix> एलिमेंट मौजूद है, तो यह <Scope> एलिमेंट वैल्यू की जगह ले लेगा. मान्य वैल्यू में, नीचे दी गई सूचियां शामिल हैं.

<Scope> एलिमेंट का इस्तेमाल <CacheKey> और <Prefix> के साथ किया जाता है. ज़्यादा जानकारी के लिए, कैश कुंजी के साथ काम करना लेख पढ़ें.

स्वीकार की जा सकने वाली वैल्यू

apifactory__test__weatherapi__16__default__apiAccessToken

<स्किपकैशलुक> एलिमेंट

यह एक एक्सप्रेशन तय करता है. अगर इसका आकलन रनटाइम के समय सही के तौर पर होता है, तो यह तय करता है कि कैश लुकअप को स्किप करना चाहिए और कैश को रीफ़्रेश किया जाना चाहिए. स्किप कैश लुकअप के इस्तेमाल के बारे में जानने के लिए यह वीडियो भी देखें.

<SkipCacheLookup>variable_condition_expression</SkipCacheLookup>

यहां दिए गए उदाहरण में से, अगर किसी इनकमिंग हेडर में बायपास-कैश वैरिएबल को 'सही' पर सेट किया गया है, तो कैश लुकअप को स्किप कर दिया जाता है. साथ ही, कैश मेमोरी को रीफ़्रेश कर दिया जाता है.

<SkipCacheLookup>request.header.bypass-cache = "true"</SkipCacheLookup>

<स्किपकैशपॉप्युलेशन> एलिमेंट

एक एक्सप्रेशन के बारे में बताता है. अगर यह रनटाइम के दौरान सही के तौर पर आकलन करता है, तो यह बताता है कि कैश मेमोरी में लिखने की सुविधा को छोड़ दिया जाना चाहिए. स्किप कैश पॉप्युलेशन के इस्तेमाल के बारे में जानने के लिए यह वीडियो भी देखें.

<SkipCachePopulation>variable_condition_expression</SkipCachePopulation>

उदाहरण के लिए, रिस्पॉन्स स्टेटस कोड 400 या इससे ज़्यादा होने पर, ये कैश मेमोरी में सेव नहीं होंगे:

<SkipCachePopulation>response.status.code >= 400</SkipCachePopulation>

<Useस्वीकारHeader> एलिमेंट

रिस्पॉन्स कैश एंट्री की कैश कुंजी को रिस्पॉन्स स्वीकार करने वाले हेडर से जोड़ी गई वैल्यू से जोड़ने के लिए, true पर सेट करें.

कैश कुंजी को कैलकुलेट करते समय, Edge Accept, Accept-Encoding, Accept-Language, और Accept-Charset अनुरोध के हेडर का इस्तेमाल करता है. इस तरीके से, क्लाइंट को उस तरह का मीडिया नहीं दिखेगा जैसा उन्होंने नहीं पूछा है.

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

ज़्यादा जानकारी के लिए कैश मेमोरी कुंजी कॉन्फ़िगर करना देखें.

<UseAcceptHeader>false</UseAcceptHeader>

<UseResponse cacheHeaders> एलिमेंट

इस वैल्यू को true पर सेट करें, ताकि कैश मेमोरी में मौजूद रिस्पॉन्स के "टाइम टू लाइव" (टीटीएल) को सेट करते समय, एचटीटीपी रिस्पॉन्स हेडर पर गौर किया जा सके. जब यह सही होता है, तब एज इन रिस्पॉन्स हेडर की वैल्यू को ध्यान में रखता है. साथ ही, लाइव होने का समय सेट करते समय, इन रिस्पॉन्स हेडर की वैल्यू की तुलना <ExpirySettings> से सेट की गई वैल्यू से की जाती है:

• Cache-Control s-maxage
• Cache-Control max-age
• Expires

ज़्यादा जानकारी के लिए, कैश मेमोरी में डेटा सेव करने की समयसीमा सेट करना देखें.

<UseResponseCacheHeaders>false</UseResponseCacheHeaders>

इस्तेमाल की जानकारी

हर कैश मेमोरी में सेव किए गए ऑब्जेक्ट का साइज़ 256 केबी से ज़्यादा नहीं होना चाहिए. (Edge कैश मेमोरी को कैसे प्रोसेस करता है, इस बारे में ज़्यादा जानकारी के लिए कैश इंटरनल लेख देखें.)

ResponseCash नीति के कॉन्फ़िगरेशन की मदद से, Edge में एचटीटीपी रिस्पॉन्स हेडर शामिल किए जा सकते हैं. ऐसा करके कैश एंट्री को खत्म करने की तारीख और कैश कुंजी सेट की जा सकती है. इस सेक्शन में बताया गया है कि कैश मेमोरी की समयसीमा खत्म होने की तारीख और कैश मेमोरी के बटन को मैनेज करने के लिए, हेडर के साथ इस नीति का इस्तेमाल किया जा सकता है.

Edge कैश मेमोरी की नीति के साथ रिस्पॉन्स हेडर को कैसे मैनेज करता है, इस बारे में ज़्यादा जानने के लिए एचटीटीपी रिस्पॉन्स हेडर के लिए सहायता लेख पढ़ें.

कैश एंट्री खत्म होने की तारीख सेट की जा रही है

कैश मेमोरी में डेटा भरने से जुड़ी नीति की तरह ही, <ExpirySettings> एलिमेंट का इस्तेमाल करके रिस्पॉन्स कैश एंट्री की समयसीमा खत्म होने की तारीख (यह समय लाइव है) सेट की जा सकती है. ResponseCash की नीति में, Edge रिस्पॉन्स हेडर मौजूद होने पर विचार करने का विकल्प भी दिया जा सकता है.

रिस्पॉन्स हेडर का इस्तेमाल करने के लिए, <UseResponseCacheHeaders> एलिमेंट वैल्यू को 'सही' पर सेट करना होता है. इस सेटिंग की वजह से, Edge रिस्पॉन्स हेडर पर गौर करता है और उनकी तुलना <ExpirySettings> की सेट की गई वैल्यू से करता है. इसके बाद, दोनों के बीच सबसे कम वैल्यू इस्तेमाल करता है. रिस्पॉन्स हेडर देखते समय, Edge यहां बताए गए तरीके से उपलब्ध वैल्यू चुनता है:

उदाहरण के लिए, मान लें कि किसी रिस्पॉन्स को इन वैल्यू के साथ कैश मेमोरी में सेव किया जाता है:

• Cache-Control s-maxage की कोई वैल्यू नहीं है
• Cache-Control max-age की वैल्यू 300
• तीन दिन में Expires तारीख
• <ExpirySettings> TimeoutInSeconds की वैल्यू 600 है.

इस मामले में, TTL (टीटीएल) के लिए Cache-Control max-age की वैल्यू का इस्तेमाल किया जाएगा, क्योंकि यह <ExpirySettings> की वैल्यू से कम है. साथ ही, इसमें Cache-Control s-maxage वैल्यू नहीं है (जिसकी प्राथमिकता max-age से ज़्यादा है).

कैश मेमोरी कुंजी को कॉन्फ़िगर करना

कैश मेमोरी से जुड़ी नीति को पॉप्युलेट करने से जुड़ी नीति जैसी सामान्य ज़रूरतों के लिए बनाई गई कैश नीतियों के तरह, आप Response कैश के साथ <CacheKey> और <Scope> एलिमेंट का इस्तेमाल करके, कैश एंट्री के लिए कैश कुंजी बनाने की सुविधा को कॉन्फ़िगर करते हैं. Response cache की मदद से कैश कुंजियों को ज़्यादा काम का बनाया जा सकता है. इसके लिए, मुख्य वैल्यू में रिस्पॉन्स स्वीकार करने के हेडर जोड़कर, ऐसा किया जा सकता है.

कैश कुंजियों को कॉन्फ़िगर करने के बारे में सामान्य जानकारी के लिए, कैश कुंजी के साथ काम करना देखें. 'स्वीकार करें' हेडर का इस्तेमाल करने के बारे में जानकारी पाने के लिए, <UseAcceptHeader> देखें.

कैश मेमोरी एन्क्रिप्ट (सुरक्षित) करने की सुविधा के बारे में जानकारी

Edge for Public Cloud: कैश मेमोरी को सिर्फ़ पीसीआई और हिपा की सुविधा वाले संगठनों में एन्क्रिप्ट (सुरक्षित) किया जाता है. उन संगठनों के लिए एन्क्रिप्शन, संगठन प्रावधान के दौरान कॉन्फ़िगर किया जाता है.

फ़्लो वैरिएबल

ResponseCash नीति के लागू होने पर, पहले से तय किए गए फ़्लो के इन वैरिएबल की जानकारी अपने-आप भर जाती है. फ़्लो वैरिएबल के बारे में ज़्यादा जानकारी के लिए, वैरिएबल रेफ़रंस देखें.

गड़बड़ी कोड

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

गड़बड़ी कोड प्रीफ़िक्स

लागू नहीं

रनटाइम से जुड़ी गड़बड़ियां

इस नीति के तहत रनटाइम में कोई गड़बड़ी नहीं होती है.

डिप्लॉयमेंट से जुड़ी गड़बड़ियां

ये गड़बड़ियां तब हो सकती हैं, जब इस नीति वाले किसी प्रॉक्सी को डिप्लॉय किया जाता है.

गड़बड़ी वाले वैरिएबल

लागू नहीं

गड़बड़ी के जवाब का उदाहरण

लागू नहीं

स्कीमा

हर तरह की नीति को एक्सएमएल स्कीमा (.xsd) से तय किया जाता है. रेफ़रंस के लिए, नीति के स्कीमा GitHub पर उपलब्ध हैं.