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

आपको 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>

Private Cloud 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 Router पर पोर्ट खुला हो.

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

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

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

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

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

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

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

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

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

ओसीएसएपी स्टैपलिंग की सुविधा चालू करने के लिए, टीएलएस चालू होना चाहिए. इसे चालू करने के लिए, 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. वाइल्डकार्ड एलियास का इस्तेमाल करने से, हर एनवायरमेंट के लिए कम वर्चुअल होस्ट इस्तेमाल किए जा सकते हैं. इससे प्रॉडक्ट की सीमाएं पार नहीं होती हैं. ऐसा इसलिए, क्योंकि वाइल्डकार्ड वाले वर्चुअल होस्ट को सिर्फ़ एक वर्चुअल होस्ट माना जाता है.

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

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

 कोई नहीं हां
इंटरफ़ेस यह सुविधा सिर्फ़ Edge for Private Cloud के लिए उपलब्ध है.
इंटरफ़ेस

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

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

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

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

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

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

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

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

HTTP 599 एक खास रिस्पॉन्स कोड है. इसे बंद किए जाने पर, Message Processor जनरेट करता है. मैसेज प्रोसेसर, सभी मौजूदा अनुरोधों को पूरा करने की कोशिश करता है. हालांकि, नए अनुरोधों के लिए वह एचटीटीपी 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 Router को किए गए अनुरोधों को मैनेज करने के लिए, टीसीपी पास-थ्रू मोड में ELB का इस्तेमाल किया है, तो राउटर, क्लाइंट के असली आईपी पते के बजाय ELB के आईपी पते को क्लाइंट आईपी के तौर पर इस्तेमाल करता है. अगर राउटर को क्लाइंट के ओरिजनल आईपी पते की ज़रूरत है, तो ELB पर proxy_protocol चालू करें, ताकि वह टीसीपी पैकेट में क्लाइंट का आईपी पता पास कर सके. राउटर पर, आपको वर्चुअल होस्ट पर <ListenOption> को proxy_protocol पर भी सेट करना होगा. ईएलबी, टीसीपी पास-थ्रू मोड में होता है. इसलिए, आम तौर पर राऊटर पर टीएलएस को बंद किया जाता है. इसलिए, आम तौर पर वर्चुअल होस्ट को proxy_protocol का इस्तेमाल करने के लिए सिर्फ़ तब कॉन्फ़िगर किया जाता है, जब उसे टीएलएस का इस्तेमाल करने के लिए भी कॉन्फ़िगर किया जाता है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

यह सुविधा, 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

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

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

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

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

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

 गलत नहीं
ClientProperties

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

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

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

proxy_read_timeout की वैल्यू, Message Processor के इस्तेमाल किए गए टारगेट टाइमआउट की वैल्यू से ज़्यादा होनी चाहिए. इससे यह पक्का होता है कि मैसेज प्रोसेसर के जवाब देने से पहले, राउटर का टाइम आउट न हो. Message Processor के लिए डिफ़ॉल्ट टारगेट टाइम आउट 55 सेकंड (55,000 मिलीसेकंड) होता है. इसे Message Processor के लिए 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.

 HIGH:!aNULL:

!MD5:

!DH+3DES:

!kEDH

 नहीं
ssl_protocols

यह सुविधा सिर्फ़ Edge for Private Cloud के लिए उपलब्ध है.

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

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

TLS प्रोटोकॉल की सूची में, प्रोटोकॉल के नाम के बीच में खाली जगह का इस्तेमाल करें. सूची इस तरह होनी चाहिए:

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

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

अगर यह सुविधा बंद है, तो बफ़रिंग बंद हो जाती है. साथ ही, अनुरोध का मुख्य हिस्सा मिलते ही, उसे मैसेज प्रोसेसर को भेज दिया जाता है. अगर कोई गड़बड़ी होती है, तो Router, अनुरोध को किसी दूसरे Message Processor को फिर से नहीं भेजता है.

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