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

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

वर्चुअल होस्ट के बारे में बताना

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

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

Cloud और Private Cloud 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._\-$%.

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

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

अगर आपने hostalias एलिमेंट में कोई पोर्ट डाला है, तो <Port> एलिमेंट में डाले गए पोर्ट नंबर का मैच होना ज़रूरी है.

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

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

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

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

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

 कोई नहीं नहीं
OCSPStapling

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

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

ओसीएसपी स्टेपल करने की सुविधा चालू करने के लिए, 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 और इसके बाद के वर्शन के लिए उपलब्ध है. साथ ही, Apigee Edge की सहायता टीम से अनुरोध करके, Edge Cloud के लिए भी यह सुविधा उपलब्ध कराई जा सकती है.
ListenOption

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

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

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

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

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

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

Cloud के लिए: आपके पास Symantec या VeriSign जैसी किसी भरोसेमंद इकाई से हस्ताक्षर किया गया सर्टिफ़िकेट होना चाहिए. आप खुद हस्ताक्षर किए हुए सर्टिफ़िकेट या लीफ़ सर्टिफ़िकेट का इस्तेमाल नहीं कर सकते. इस पर आपने अपने हस्ताक्षर किए हुए सीए (सर्टिफ़िकेट देने वाली संस्था) से हस्ताक्षर किए हैं.

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

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

Edge पर मौजूद पासकोड स्टोर का नाम.

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

 कोई नहीं Enabled के 'सही' होने पर हां
KeyAlias कीस्टोर में सर्टिफ़िकेट और निजी कुंजी अपलोड करते समय दिया गया उपनाम. आपको अंग्रेज़ी में ही, बदलाव किए गए नाम की जानकारी देनी होगी. रेफ़रंस का इस्तेमाल नहीं किया जा सकता. ज़्यादा जानकारी के लिए, TLS को कॉन्फ़िगर करने के विकल्प देखें. कोई नहीं Enabled के 'सही' होने पर हां
TrustStore

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

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

 कोई नहीं नहीं
IgnoreValidationErrors

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

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

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

 गलत नहीं
साइफ़र

सिर्फ़ Edge for Private Cloud के 4.15.07 और उससे पहले के वर्शन के लिए.

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

सिफर को सीमित करने के लिए, ये एलिमेंट जोड़ें:

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

सिर्फ़ Edge for Private Cloud के 4.15.07 और उससे पहले के वर्शन के लिए.

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

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

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

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

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

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

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

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

 गलत नहीं
ClientProperties

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

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

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

proxy_read_timeout की वैल्यू, मैसेज प्रोसेसर के इस्तेमाल की गई टारगेट टाइम आउट वैल्यू से ज़्यादा होनी चाहिए. इससे यह पक्का होता है कि मैसेज प्रोसेसर के रिस्पॉन्स देने से पहले, रूटर टाइम आउट न हो जाए. मैसेज प्रोसेसर के लिए, डिफ़ॉल्ट टारगेट टाइम आउट 55 सेकंड, 55,000 मिलीसेकंड है, जैसा कि मैसेज प्रोसेसर के लिए 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 देखें. ध्यान दें कि यह टोकन, OpenSSL सिफर के नामों का इस्तेमाल करता है, जैसे कि AES128-SHA256. यह Java/JSSE सिफर के नामों का इस्तेमाल नहीं करता, जैसे कि TLS_RSA_WITH_AES_128_CBC_SHA256.

 ज़्यादा:!aशून्य:

!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 इससे जवाब को बफ़र करने की सुविधा चालू (चालू) या बंद (बंद) होती है. बफ़र करने की सुविधा चालू होने पर, राऊटर रिस्पॉन्स को बफ़र करता है. बफ़र करने की सुविधा बंद होने पर, जवाब तुरंत क्लाइंट को भेज दिया जाता है, जैसे ही वह राउटर को मिलता है. चालू है नहीं