वर्चुअल होस्ट प्रॉपर्टी का रेफ़रंस

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

वर्चुअल होस्ट का प्रतिनिधित्व

वर्चुअल होस्ट तय करने के लिए जिस एक्सएमएल ऑब्जेक्ट का इस्तेमाल किया जाता है वह आपके EDGE: Cloud या Private Cloud के वर्शन पर आधारित होता है.

अगर आप Private Cloud के ग्राहक हैं, तो यह पक्का करें कि आपने Edge के अपने वर्शन के लिए सही एक्सएमएल का इस्तेमाल किया हो.

क्लाउड और प्राइवेट क्लाउड 4.17.01 और उसके बाद के वर्शन

<VirtualHost name="vhostName">
    <Port>portNumber</Port>
    <BaseUrl>http://myCo.com</BaseUrl>
    <OCSPStapling>offOn</OCSPStapling>
    <HostAliases>
        <HostAlias>hostAlias</HostAlias>
    </HostAliases>
    <Interfaces>
        <!-- Private Cloud only -->
        <Interface>interfaceName</Interface>
    </Interfaces>
    <RetryOptions>
        <RetryOption>option</RetryOption>
    </RetryOptions>
    <ListenOptions>
        <ListenOption>option</ListenOption>
    </ListenOptions>
    <SSLInfo>
        <Enabled>trueFalse</Enabled>
        <ClientAuthEnabled>trueFalse</ClientAuthEnabled>
        <KeyStore>ref://keystoreRef</KeyStore>
        <KeyAlias>keyAlias</KeyAlias>
        <TrustStore>ref://truststoreRef</TrustStore>
        <IgnoreValidationErrors>trueFalse</IgnoreValidationErrors>
    </SSLInfo>
    <!-- UseBuiltInFreeTrialCert is for Edge Cloud only -->
    <UseBuiltInFreeTrialCert>trueFalse</UseBuiltInFreeTrialCert>
    <PropagateTLSInformation>
        <!-- PropagateTLSInformation is Alpha in the Cloud only -->
        <ConnectionProperties>trueFalse</ConnectionProperties>
        <ClientProperties>trueFalse</ClientProperties>
    </PropagateTLSInformation>
    <Properties>
        <Property name="proxy_read_timeout">timeout</Property>
        <Property name="keepalive_timeout">timeout</Property>
        <Property name="proxy_request_buffering">onOff</Property>
        <Property name="proxy_buffering">onOff</Property>
        <!-- ssl_protocols is Private Cloud only -->
        <Property name="ssl_protocols">protocolList</Property>
        <Property name="ssl_ciphers">cipherList</Property>
    </Properties>
</VirtualHost>

प्राइवेट क्लाउड 4.16.01 से 4.16.09 तक

<VirtualHost name="vhostName">
    <Port>portNumber</Port>
    <HostAliases>
        <HostAlias>hostAlias</HostAlias>
    </HostAliases>
    <Interfaces>
        <Interface>interfaceName</Interface>
    </Interfaces>
    <SSLInfo>
        <Enabled>trueFalse</Enabled>
        <ClientAuthEnabled>trueFalse</ClientAuthEnabled>
        <KeyStore>ref://keystoreRef</KeyStore>
        <KeyAlias>keyAlias</KeyAlias>
        <TrustStore>ref://truststoreRef</TrustStore>
        <IgnoreValidationErrors>trueFalse</IgnoreValidationErrors>
    </SSLInfo>
</VirtualHost>

Private Cloud 4.15.07 और इससे पहले के वर्शन

<VirtualHost name="vhostName">
    <Port>portNumber</Port>
    <HostAliases>
        <HostAlias>hostAlias</HostAlias>
    </HostAliases>
    <Interfaces>
        <Interface>interfaceName</Interface>
    </Interfaces>
    <SSLInfo>
        <Enabled>trueFalse</Enabled>
        <ClientAuthEnabled>trueFalse</ClientAuthEnabled>
        <KeyStore>keystore</KeyStore>
        <KeyAlias>keyAlias</KeyAlias>
        <TrustStore>truststore</TrustStore>
        <IgnoreValidationErrors>trueFalse</IgnoreValidationErrors>
        <Ciphers>
             <Cipher>cipher</Cipher>
             <Cipher>cipher</Cipher>
         </Ciphers>
         <Protocols>
             <Protocol>protocol</Protocol>
             <Protocol>protocol</Protocol>
         </Protocols>
    </SSLInfo>
</VirtualHost>

वर्चुअल होस्ट कॉन्फ़िगरेशन की प्रॉपर्टी

इस टेबल में उन प्रॉपर्टी की सूची दी गई है जिनका इस्तेमाल करके, वर्चुअल होस्ट को कॉन्फ़िगर किया जाता है:

प्रॉपर्टी ब्यौरा डिफ़ॉल्ट ज़रूरी है
VirtualHost

वर्चुअल होस्ट का नाम बताता है. एपीआई प्रॉक्सी को कॉन्फ़िगर करते समय, वर्चुअल होस्ट का रेफ़रंस देने के लिए, उस नाम का इस्तेमाल किया जाता है.

नाम एट्रिब्यूट में, इन वर्णों का इस्तेमाल किया जा सकता है: A-Z0-9._\-$%.

 कभी नहीं हां
पोर्ट

इससे उस पोर्ट नंबर के बारे में पता चलता है जिसका इस्तेमाल वर्चुअल होस्ट करता है. पक्का करें कि Edge राऊटर पर पोर्ट खुला हो.

अगर आप किसी hostalias एलिमेंट में पोर्ट की जानकारी देते हैं, तो <Port> का तय किया गया पोर्ट नंबर उससे मेल खाना चाहिए.

क्लाउड के लिए: वर्चुअल होस्ट बनाते समय, आपको पोर्ट 443 की जानकारी देनी होगी. अगर इसे छोड़ा जाता है, तो डिफ़ॉल्ट रूप से पोर्ट 443 पर सेट होता है. अगर आपका कोई मौजूदा वर्चुअल होस्ट है, जो 443 के अलावा किसी पोर्ट का इस्तेमाल करता है, तो आप पोर्ट को नहीं बदल सकते.

निजी क्लाउड के 4.16.01 से लेकर 4.17.05 तक: वर्चुअल होस्ट बनाते समय, आपको वह राऊटर पोर्ट बताना होता है जिसका इस्तेमाल वर्चुअल होस्ट करता है. उदाहरण के लिए, पोर्ट 9001. डिफ़ॉल्ट रूप से, राऊटर, उपयोगकर्ता "apigee" के तौर पर चलता है. इसके पास, खास अधिकार वाले पोर्ट का ऐक्सेस नहीं होता. आम तौर पर, राऊटर 1024 और इससे पहले के पोर्ट होता है. अगर आपको ऐसा वर्चुअल होस्ट बनाना है जो राऊटर को सुरक्षित पोर्ट से बाइंड करता है, तो आपको उस उपयोगकर्ता के तौर पर चलाने के लिए राऊटर को कॉन्फ़िगर करना होगा जिसके पास उन पोर्ट का ऐक्सेस हो. ज़्यादा जानकारी के लिए, वर्चुअल होस्ट सेट अप करना देखें.

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

 कभी नहीं हां
BaseUrl यह वर्चुअल होस्ट पर डिप्लॉय किए गए एपीआई प्रॉक्सी के लिए, Edge यूज़र इंटरफ़ेस (यूआई) में दिखाए गए यूआरएल को बदल देता है. यह तब काम आता है, जब आपके पास Edge राऊटर के सामने एक्सटर्नल लोड बैलेंसर हो. ज़्यादा जानकारी के लिए, प्राइवेट क्लाउड के लिए, TLS के ऐक्सेस को एपीआई के लिए कॉन्फ़िगर करना देखें.

BaseUrl की वैल्यू में प्रोटोकॉल शामिल होना चाहिए (जैसे, "http://" या "https://").

 कभी नहीं नहीं
OCSPStapling

OCSP (ऑनलाइन सर्टिफ़िकेट स्टेटस प्रोटोकॉल) क्लाइंट, OCSP के जवाब देने वाले व्यक्ति को स्टेटस का अनुरोध भेजता है. इससे यह पता चलता है कि TLS सर्टिफ़िकेट मान्य है या नहीं. रिस्पॉन्स बताता है कि TLS सर्टिफ़िकेट मान्य है और उसे वापस नहीं लिया गया है.

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

ओसीएसपी स्टेपलिंग चालू करने के लिए, TLS को चालू करना ज़रूरी है. चालू करने के लिए, on पर सेट करें. डिफ़ॉल्ट वैल्यू off है.

बंद है नहीं
HostAliases
HostAlias

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

आपको ऐसी डीएनएस एंट्री और CNAME रिकॉर्ड बनाना होगा जो होस्ट के उपनाम से मेल खाता हो. साथ ही, होस्ट उपनाम उस स्ट्रिंग से मेल खाना चाहिए जिसे क्लाइंट, Host हेडर में पास करता है.

HostAlias में पोर्ट नंबर डालना ज़रूरी नहीं है. अगर आपने पोर्ट को होस्ट के उपनाम के हिस्से के तौर पर बताया है, तो आपको <Port> एलिमेंट का इस्तेमाल करके उसी पोर्ट के बारे में भी बताना होगा. इसके अलावा, दो HostAlias एलिमेंट जोड़े जा सकते हैं, एक के साथ पोर्ट नंबर और दूसरा, बिना पोर्ट नंबर के.

आपके पास एक ही वर्चुअल होस्ट की परिभाषा में, HostAlias के लिए एक से ज़्यादा परिभाषाएं हो सकती हैं. ये परिभाषाएं, वर्चुअल होस्ट के लिए एक से ज़्यादा डीएनएस एंट्री से मिलती-जुलती हो सकती हैं. हालांकि, एक से ज़्यादा पोर्ट के लिए ऐसा नहीं किया जा सकता. अगर आपको एक से ज़्यादा पोर्ट चाहिए, तो अलग-अलग पोर्ट के साथ एक से वर्चुअल होस्ट परिभाषाएं बनाएं.

होस्ट के उपनाम में "*" वाइल्डकार्ड वर्ण शामिल किया जा सकता है. "*" वाइल्डकार्ड वर्ण सिर्फ़ होस्ट उपनाम की शुरुआत में (पहले "." से पहले) हो सकता है और इसे दूसरे वर्णों के साथ नहीं मिलाया जा सकता. उदाहरण के लिए, *.example.com. वर्चुअल होस्ट के TLS सर्टिफ़िकेट में, सर्टिफ़िकेट के सीएन नाम में मिलता-जुलता वाइल्डकार्ड होना ज़रूरी है. उदाहरण के लिए, *.example.com. वर्चुअल होस्ट के उपनाम में वाइल्डकार्ड का इस्तेमाल करने से, एपीआई प्रॉक्सी, alpha.example.com, beta.example.com या live.example.com जैसे एक से ज़्यादा सबडोमेन पर भेजे गए कॉल को हैंडल कर सकते हैं. वाइल्डकार्ड उपनाम का इस्तेमाल करने से, आपको प्रॉडक्ट की तय सीमाओं के अंदर रहने के लिए हर एनवायरमेंट में कम वर्चुअल होस्ट का इस्तेमाल करने में मदद मिलती है. ऐसा इसलिए होता है, क्योंकि वाइल्डकार्ड वाले वर्चुअल होस्ट को एक ही वर्चुअल होस्ट के तौर पर गिना जाता है.

क्लाउड के लिए: अगर आपके पास कोई मौजूदा वर्चुअल होस्ट है जो 443 के अलावा किसी पोर्ट का इस्तेमाल करता है, तो आपके पास होस्ट उपनाम को जोड़ने या हटाने की सुविधा नहीं होती.

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

 कभी नहीं हां
इंटरफ़ेस यह सुविधा सिर्फ़ प्राइवेट क्लाउड में Edge के साथ उपलब्ध है.
इंटरफ़ेस

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

उदाहरण के लिए, पोर्ट को सिर्फ़ en0 से बाइंड करने के लिए तय करने के लिए:

<Interfaces>
  <Interface>en0</Interface>
</Interfaces>

"ifconfig -a" कमांड चलाकर, अपने सिस्टम पर उपलब्ध इंटरफ़ेस तय करें.

 कभी नहीं सभी इंटरफ़ेस
RetryOptions Edge Cloud और Private Cloud 4.18.01 और इसके बाद के वर्शन के लिए उपलब्ध है.
RetryOption

कॉन्फ़िगर करें कि मैसेज प्रोसेसर के बंद होने पर, राऊटर इस वर्चुअल होस्ट के लिए कैसे प्रतिक्रिया देता है.

<RetryOption> का इस्तेमाल करके, एक से ज़्यादा वैल्यू तय की जा सकती हैं. मान्य वैल्यू में ये शामिल हैं:

off इससे 'फिर से कोशिश करें' सुविधा बंद हो जाती है. साथ ही, अनुरोध करने पर वर्चुअल होस्ट, काम न करने वाला कोड दिखाता है.
http_599 (डिफ़ॉल्ट) अगर राऊटर को मैसेज प्रोसेसर से एचटीटीपी 599 रिस्पॉन्स मिलता है, तो राऊटर अनुरोध को अगले मैसेज प्रोसेसर पर फ़ॉरवर्ड कर देता है.

HTTP 599 एक खास रिस्पॉन्स कोड है. यह मैसेज प्रोसेसर से तब जनरेट होता है, जब इसे शट डाउन किया जा रहा हो. मैसेज प्रोसेसर, सभी मौजूदा अनुरोधों को पूरा करने की कोशिश करता है. हालांकि, किसी भी नए अनुरोध के लिए यह एचटीटीपी 599 के साथ रिस्पॉन्स देता है, ताकि राऊटर को अगले मैसेज प्रोसेसर पर फिर से अनुरोध करने का सिग्नल भेजा जा सके.
error अगर मैसेज प्रोसेसर के साथ कनेक्शन बनाने, उस पर अनुरोध पास करने या उससे रिस्पॉन्स हेडर को पढ़ने के दौरान कोई गड़बड़ी हुई है, तो राऊटर इस अनुरोध को अगले मैसेज प्रोसेसर पर फ़ॉरवर्ड कर देता है.
timeout अगर मैसेज प्रोसेसर के साथ कनेक्शन बनाने, उस अनुरोध को पास करने या उससे रिस्पॉन्स हेडर को पढ़ने के दौरान टाइम आउट हो जाता है, तो राऊटर इस अनुरोध को अगले मैसेज प्रोसेसर पर फ़ॉरवर्ड कर देता है.
invalid_header अगर मैसेज प्रोसेसर से कोई खाली या अमान्य जवाब मिलता है, तो राऊटर उस अनुरोध को अगले मैसेज प्रोसेसर पर भेज देता है.
http_XXX अगर मैसेज प्रोसेसर से एचटीटीपी कोड XXX मिलता है, तो राऊटर इस अनुरोध को अगले मैसेज प्रोसेसर पर भेज देता है.

अगर एक से ज़्यादा वैल्यू दी गई हैं, तो राऊटर उन्हें जोड़ने के लिए लॉजिकल OR का इस्तेमाल करता है.

उदाहरण के लिए:

<RetryOptions>
  <RetryOption>http_599</RetryOption>
  <RetryOption>error</RetryOption>
  <RetryOption>timeout</RetryOption>
  <RetryOption>invalid_header</RetryOption>
</RetryOptions>
ListenOptions यह सुविधा, Private Cloud 4.18.01 और इसके बाद के वर्शन और Edge Cloud के लिए उपलब्ध है. इसके लिए, Apigee Edge की सहायता टीम से अनुरोध करें.
ListenOption

अगर Edge राऊटर को अनुरोध भेजने के लिए टीसीपी पास-थ्रू मोड में ईएलबी का इस्तेमाल किया जाता है, तो राऊटर, असल क्लाइंट आईपी के बजाय ईएलबी के आईपी पते को क्लाइंट आईपी मानता है. अगर राऊटर को सही क्लाइंट आईपी की ज़रूरत है, तो ईएलबी पर proxy_protocol चालू करें, ताकि यह टीसीपी पैकेट में क्लाइंट आईपी पास कर सके. राऊटर पर, आपको वर्चुअल होस्ट पर <ListenOption> को भी proxy_protocol पर सेट करना होगा. ईएलबी, टीसीपी पास-थ्रू मोड में है. इसलिए, आम तौर पर राऊटर पर TLS को बंद कर दिया जाता है. इसलिए, आम तौर पर आप वर्चुअल होस्ट को proxy_protocol का इस्तेमाल करने के लिए सिर्फ़ तब कॉन्फ़िगर करते हैं, जब उसे TLS का इस्तेमाल करने के लिए भी कॉन्फ़िगर किया जाता है.

<ListenOption> के लिए डिफ़ॉल्ट वैल्यू, खाली स्ट्रिंग होती है.

उदाहरण के लिए:

<ListenOptions>
  <ListenOption>proxy_protocol</ListenOption>
</ListenOptions>

बाद में, <ListenOption> को अनसेट करने के लिए, वर्चुअल होस्ट को अपडेट करें और <ListenOptions> टैग को अपडेट में शामिल न करें.
SSLInfo
चालू

एकतरफ़ा TLS/एसएसएल चालू करता है. आपको ऐसा कीस्टोर तय करना होगा जिसमें सर्टिफ़िकेट और निजी पासकोड शामिल हो.

क्लाउड के लिए: आपके पास Symantec या VeriSign जैसी किसी भरोसेमंद इकाई से हस्ताक्षर किया गया सर्टिफ़िकेट होना चाहिए. आप खुद हस्ताक्षर किए गए प्रमाणपत्र का इस्तेमाल नहीं कर सकते, लीफ़ सर्टिफ़िकेट को खुद हस्ताक्षर करने वाले CA से हस्ताक्षर नहीं कर सकते.

क्लाउड के लिए: अगर आपके मौजूदा वर्चुअल होस्ट को 443 के अलावा, किसी दूसरे पोर्ट का इस्तेमाल करने के लिए कॉन्फ़िगर किया गया है, तो TLS की सेटिंग में बदलाव नहीं किया जा सकता. इसका मतलब है कि TLS की सेटिंग को 'चालू है' से 'बंद है' या 'बंद है' से 'चालू है' में नहीं बदला जा सकता.

false नहीं
ClientAuthEnabled यह सुविधा, Edge (सर्वर) और अनुरोध करने वाले ऐप्लिकेशन (क्लाइंट) के बीच, टू-वे या क्लाइंट TLS को चालू करती है. टू-वे TLS चालू करने के लिए, Edge पर ऐसा ट्रस्टस्टोर सेट अप करना ज़रूरी है जिसमें TLS क्लाइंट का सर्टिफ़िकेट शामिल हो. false नहीं
KeyStore

Edge पर कीस्टोर का नाम.

Apigee का सुझाव है कि आप कीस्टोर का नाम बताने के लिए, एक रेफ़रंस का इस्तेमाल करें, ताकि आप राऊटर को रीस्टार्ट किए बिना कीस्टोर बदल सकें. ज़्यादा जानकारी के लिए, TLS को कॉन्फ़िगर करने के तरीके देखें.

 कभी नहीं अगर यह नीति चालू है, तो हां
KeyAlias यह वह उपनाम है जो कीस्टोर में सर्टिफ़िकेट और निजी पासकोड को अपलोड करते समय दिया गया था. आपको उपनाम का इस्तेमाल वाकई करना होगा; रेफ़रंस का इस्तेमाल नहीं किया जा सकता. ज़्यादा जानकारी के लिए, TLS को कॉन्फ़िगर करने के विकल्प देखें. कभी नहीं अगर यह नीति चालू है, तो हां
TrustStore

Edge पर मौजूद उस ट्रस्टस्टोर का नाम जिसमें टू-वे TLS के लिए इस्तेमाल किया जाने वाला सर्टिफ़िकेट या सर्टिफ़िकेट चेन होता है. अगर <ClientAuthEnabled> सही है, तो इसे भरना ज़रूरी है.

Apigee आपको ट्रस्टस्टोर का नाम बताने के लिए एक रेफ़रंस इस्तेमाल करने का सुझाव देता है, ताकि आप राऊटर को रीस्टार्ट किए बिना ट्रस्टस्टोर बदल सकें. ज़्यादा जानकारी के लिए, TLS को कॉन्फ़िगर करने के तरीके देखें.

 कभी नहीं नहीं
IgnoreValidationErrors

सही होने पर, यह TLS सर्टिफ़िकेट से जुड़ी गड़बड़ियों को अनदेखा करने के लिए तय करता है. यह "-k" विकल्प, cURL की तरह है.

यह विकल्प टारगेट सर्वर और टारगेट एंडपॉइंट के लिए TLS को कॉन्फ़िगर करते समय मान्य होता है. साथ ही, यह 2-वे TLS का इस्तेमाल करने वाले वर्चुअल होस्ट को कॉन्फ़िगर करते समय भी मान्य होता है.

टारगेट एंडपॉइंट/टारगेट सर्वर के साथ इस्तेमाल किए जाने पर, अगर बैकएंड सिस्टम SNI का इस्तेमाल करता है और होस्टनेम से मेल न खाने वाले सब्जेक्ट के खास नाम (डीएन) वाला सर्टिफ़िकेट दिखाता है, तो गड़बड़ी को अनदेखा करने और कनेक्शन के काम न करने पर, कोई तरीका नहीं होता.

 false नहीं
साइफ़र

सिर्फ़ प्राइवेट क्लाउड वर्शन 4.15.07 और इससे पहले के वर्शन के लिए.

वर्चुअल होस्ट के साथ काम करने वाले साइफ़र तय करता है. अगर कोई साइफ़र तय नहीं किया गया है, तो जेवीएम के लिए उपलब्ध सभी साइफ़र को अनुमति दी जाएगी.

साइफ़र पर पाबंदी लगाने के लिए, इन एलिमेंट को जोड़ें:

<Ciphers>
  <Cipher>TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA</Cipher>
  <Cipher>TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256</Cipher>
</Ciphers>
 ये सभी जेवीएम के साथ काम करते हैं नहीं
प्रोटोकॉल

सिर्फ़ प्राइवेट क्लाउड वर्शन 4.15.07 और इससे पहले के वर्शन के लिए.

वर्चुअल होस्ट के साथ काम करने वाले प्रोटोकॉल के बारे में बताता है. अगर कोई प्रोटोकॉल तय नहीं किया गया है, तो जेवीएम के लिए उपलब्ध सभी प्रोटोकॉल को अनुमति दी जाएगी.

प्रोटोकॉल पर पाबंदी लगाने के लिए, इन एलिमेंट को जोड़ें:

<Protocols>
  <Protocol>TLSv1</Protocol>
  <Protocol>TLSv1.2</Protocol>
  <Protocol>SSLv2Hello</Protocol>
</Protocols>
 ये सभी जेवीएम के साथ काम करते हैं नहीं
UseBuiltInFreeTrialCert यह सुविधा सिर्फ़ Edge Cloud के लिए उपलब्ध है.
UseBuiltInFreeTrialCert

अगर आपके पास Cloud खाते के लिए पैसे चुकाकर इस्तेमाल किया जाने वाला EDGE है और आपके पास TLS सर्टिफ़िकेट और कुंजी नहीं है, तो एक वर्चुअल होस्ट बनाया जा सकता है. यह होस्ट, Apigee के मुफ़्त में आज़माने की अवधि वाले सर्टिफ़िकेट और कुंजी का इस्तेमाल करता है. इसका मतलब है कि आपके पास कीस्टोर बनाए बिना, वर्चुअल होस्ट बनाने का विकल्प है.

*.apigee.net के डोमेन के लिए, Apigee को मुफ़्त में आज़माने का सर्टिफ़िकेट तय किया गया है. इसलिए, वर्चुअल होस्ट का <HostAlias> भी *.apigee.net फ़ॉर्म में होना चाहिए.

Apigee के मुफ़्त में आज़माने की अवधि और कुंजी का इस्तेमाल करने वाला वर्चुअल होस्ट तय करना देखें.

 false नहीं
PropagateTLSInformation यह सुविधा सिर्फ़ Edge Cloud के लिए ऐल्फ़ा वर्शन में उपलब्ध है.
ConnectionProperties

इस नीति की मदद से, Edge से TLS कनेक्शन की जानकारी को कैप्चर किया जा सकता है. इसके बाद, यह जानकारी किसी एपीआई प्रॉक्सी में फ़्लो वैरिएबल के तौर पर उपलब्ध होती है. ज़्यादा जानकारी के लिए, एपीआई प्रॉक्सी में TLS कनेक्शन की जानकारी ऐक्सेस करना देखें.

 false नहीं
ClientProperties

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

 false नहीं
प्रॉपर्टी Edge Cloud और Private Cloud 4.17.01 और इसके बाद के वर्शन के लिए उपलब्ध है.
proxy_read_timeout

मैसेज प्रोसेसर और राऊटर के बीच टाइम आउट की अवधि को सेकंड में सेट करता है. अगर राऊटर, कनेक्शन को बंद कर देता है और इस अवधि के खत्म होने से पहले उसे मैसेज प्रोसेसर से कोई जवाब नहीं मिलता, तो एचटीटीपी 504 रिस्पॉन्स नहीं देता.

प्रॉक्सी_read_timeout की वैल्यू, मैसेज प्रोसेसर के इस्तेमाल किए जाने वाले टारगेट टाइम आउट की वैल्यू से ज़्यादा होनी चाहिए. इससे यह पक्का होता है कि मैसेज प्रोसेसर को जवाब देने का समय मिलने से पहले, राऊटर टाइम आउट नहीं होगा. Message प्रोसेसर के लिए डिफ़ॉल्ट टारगेट टाइम आउट 55 सेकंड, 55,000 मिलीसेकंड है, जैसा कि Message प्रोसेसर के conf_http_HTTPTransport.io.timeout.millis टोकन में बताया गया है.

 57 नहीं
keepalive_timeout

जब क्लाइंट, Keep-Alive हेडर वाला अनुरोध करता है, तो क्लाइंट और राऊटर के बीच टाइम आउट की अवधि, सेकंड में सेट करती है. राऊटर, कनेक्शन को तब तक चालू रखता है, जब तक समयसीमा खत्म नहीं हो जाती.

अगर राऊटर, मैसेज प्रोसेसर से जवाब का इंतज़ार कर रहा है, तो कनेक्शन बंद नहीं करेगा. टाइम आउट सिर्फ़ तब शुरू होता है, जब राऊटर, क्लाइंट को जवाब देता है.

 65 नहीं
ssl_ciphers

यह वर्चुअल होस्ट के साथ काम करने वाले साइफ़र सेट करता है और राऊटर पर सेट किए गए डिफ़ॉल्ट साइफ़र को ओवरराइड करता है.

इस फ़ॉर्म में, साइफ़र की कोलन से अलग करके बनाई गई सूची बताएं:

<Property name="ssl_ciphers">HIGH:!aNULL:!MD5:!DH+3DES:!kEDH;</Property>

सिंटैक्स और इस टोकन से मंज़ूर की गई वैल्यू के बारे में जानकारी के लिए, https://www.openssl.org/docs/man1.0.2/man1/ciphers.html पर जाएं. ध्यान दें कि इस टोकन में, JavaScript के साइफ़र नेम, जैसे कि AES128-SHA256 का इस्तेमाल किया जाता है, न कि Java/JSSE साइफ़र नेम, जैसे कि TLS_RSA_WITH_AES_128_CBC_SHA256.

 ज़्यादा:!aNULL:

!MD5:

!DH+3DES:

!केईडीएच

 नहीं
ssl_protocols

यह सुविधा सिर्फ़ प्राइवेट क्लाउड में Edge के साथ उपलब्ध है.

यह रूटर पर सेट किए गए डिफ़ॉल्ट प्रोटोकॉल को ओवरराइड करके, वर्चुअल होस्ट पर काम करने वाले TLS प्रोटोकॉल को स्पेस डिलिमिटेड सूची के तौर पर सेट करता है.

ध्यान दें: अगर दो वर्चुअल होस्ट एक ही पोर्ट को शेयर करते हैं, तो उन्हें ssl_protocols को एक ही प्रोटोकॉल पर सेट करना होगा. इसका मतलब है कि एक ही पोर्ट वाले वर्चुअल होस्ट को एक जैसे प्रोटोकॉल के साथ काम करना चाहिए.

यह फ़ॉर्म में TLS प्रोटोकॉल की स्पेस-डीलिमिटेड सूची दिखाता है:

<Property name="ssl_protocols">TLSv1 TLSv1.2</Property>
 TLSv1 TLSv1.1 TLSv1.2 नहीं
proxy_request_buffering

अनुरोध के मुख्य हिस्से की बफ़रिंग को चालू (चालू) या बंद (बंद) करता है. बफ़र होने की सुविधा चालू होने पर, राऊटर को मैसेज प्रोसेसर पर भेजने से पहले अनुरोध के पूरे मुख्य हिस्से को बफ़र कर देता है. अगर कोई गड़बड़ी होती है, तो राऊटर किसी दूसरे मैसेज प्रोसेसर को फिर से कोशिश कर सकता है.

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

 चालू है नहीं
proxy_buffering जवाब की बफ़रिंग को चालू (चालू) या बंद (बंद) करता है. बफ़र होने की सुविधा चालू होने पर, राऊटर रिस्पॉन्स को बफ़र कर देता है. जब बफ़रिंग की सुविधा बंद होती है, तब राऊटर को रिस्पॉन्स मिलते ही, क्लाइंट को रिस्पॉन्स तुरंत भेज दिया जाता है. चालू है नहीं