एंडपॉइंट प्रॉपर्टी का रेफ़रंस

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

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

TargetEndpoint की ट्रांसपोर्ट प्रॉपर्टी

TargetEndpoint के कॉन्फ़िगरेशन में मौजूद HTTPTargetConnection एलिमेंट, एचटीटीपी ट्रांसपोर्ट की प्रॉपर्टी का सेट तय करता है. ट्रांसपोर्ट-लेवल के कॉन्फ़िगरेशन सेट करने के लिए, इन प्रॉपर्टी का इस्तेमाल किया जा सकता है.

प्रॉपर्टी को TargetEndpoint के HTTPTargetConnection एलिमेंट पर, यहां दिखाए गए तरीके से सेट किया जाता है:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <URL>http://mocktarget.apigee.net</URL>
    <Properties>
      <Property name="supports.http10">true</Property>
      <Property name="request.retain.headers">User-Agent,Referer,Accept-Language</Property>
      <Property name="retain.queryparams">apikey</Property>
    </Properties>
    <CommonName>COMMON_NAME_HERE</CommonName>
  </HTTPTargetConnection>
</TargetEndpoint>

TargetEndpoint की ट्रांसपोर्ट प्रॉपर्टी की खास जानकारी

प्रॉपर्टी का नाम डिफ़ॉल्ट मान ब्यौरा
keepalive.timeout.millis 60000 कनेक्शन पूल में, टारगेट कनेक्शन के लिए कनेक्शन का आइडल टाइमआउट. अगर पूल में मौजूद कनेक्शन, तय की गई सीमा से ज़्यादा समय तक आइडल रहता है, तो कनेक्शन बंद कर दिया जाता है.
connect.timeout.millis

3000

टारगेट कनेक्शन का टाइमआउट. अगर कनेक्शन टाइमआउट होता है, तो Edge, एचटीटीपी 503 स्टेटस कोड दिखाता है. कुछ मामलों में, एचटीटीपी 504 स्टेटस कोड तब दिखाया जा सकता है, जब LoadBalancer का इस्तेमाल TargetServer परिभाषा में किया जाता है और टाइमआउट होता है.

io.timeout.millis 55000

अगर तय किए गए मिलीसेकंड तक कोई डेटा नहीं पढ़ा जाता है या अगर सॉकेट तय किए गए मिलीसेकंड तक डेटा लिखने के लिए तैयार नहीं है, तो लेन-देन को टाइमआउट माना जाता है.

  • अगर एचटीटीपी अनुरोध लिखते समय टाइमआउट होता है, तो 408, Request Timeout दिखाया जाता है.
  • अगर एचटीटीपी रिस्पॉन्स पढ़ते समय टाइमआउट होता है, तो 504, Gateway Timeout दिखाया जाता है.

इस वैल्यू को हमेशा वर्चुअल होस्ट की proxy_read_timeout प्रॉपर्टी की वैल्यू से कम होना चाहिए.

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

ज़्यादा जानकारी के लिए, Edge के लिए io.timeout.millis और api.timeout सेट करना देखें.
supports.http10 true अगर यह true है और क्लाइंट 1.0 का अनुरोध भेजता है, तो टारगेट को भी 1.0 अनुरोध भेजा जाता है. वरना, टारगेट को 1.1 का अनुरोध भेजा जाता है.
supports.http11 true अगर यह true है और क्लाइंट 1.1 का अनुरोध भेजता है, तो टारगेट को भी 1.1 अनुरोध भेजा जाता है. वरना, टारगेट को 1.0 का अनुरोध भेजा जाता है.
use.proxy true अगर इसे true पर सेट किया जाता है और प्रॉक्सी कॉन्फ़िगरेशन http.properties (सिर्फ़ कंपनी की इमारत में डिप्लॉयमेंट के लिए) में तय किए जाते हैं, तो टारगेट कनेक्शन तय की गई प्रॉक्सी का इस्तेमाल करने के लिए सेट किए जाते हैं.
use.proxy.tunneling true अगर इसे true पर सेट किया जाता है और http.properties (सिर्फ़ ऑन-प्रिमाइसेस डिप्लॉयमेंट के लिए) में प्रॉक्सी कॉन्फ़िगरेशन तय किए जाते हैं, तो टारगेट कनेक्शन, तय किए गए टनल का इस्तेमाल करने के लिए सेट किए जाते हैं. अगर टारगेट, टीएलएस/एसएसएल का इस्तेमाल करता है, तो इस प्रॉपर्टी को अनदेखा कर दिया जाता है. साथ ही, मैसेज हमेशा टनल के ज़रिए भेजा जाता है.
enable.method.override false तय किए गए एचटीटीपी मेथड के लिए, टारगेट सेवा को भेजे जाने वाले आउटबाउंड अनुरोध पर X-HTTP-Method-Override हेडर सेट करता है. उदाहरण के लिए, <Property name="GET.override.method">POST</Property>
*.override.method लागू नहीं तय किए गए एचटीटीपी मेथड के लिए, आउटबाउंड अनुरोध पर X-HTTP-Method-Override हेडर सेट करता है. उदाहरण के लिए, <Property name="GET.override.method">POST</Property>
request.streaming.enabled false

डिफ़ॉल्ट तौर पर (false), एचटीटीपी अनुरोध के पेलोड को बफ़र में पढ़ा जाता है. साथ ही, पेलोड पर काम करने वाली नीतियां, उम्मीद के मुताबिक काम करती हैं. अगर पेलोड, बफ़र के साइज़ (10 एमबी) से बड़े हैं, तो इस एट्रिब्यूट को true पर सेट किया जा सकता है. जब true होता है, तो एचटीटीपी अनुरोध के पेलोड को बफ़र में नहीं पढ़ा जाता. उन्हें टारगेट एंडपॉइंट पर, बिना किसी बदलाव के स्ट्रीम किया जाता है. इस मामले में, TargetEndpoint के अनुरोध फ़्लो में पेलोड पर काम करने वाली सभी नीतियां बायपास हो जाती हैं. अनुरोधों और जवाबों को स्ट्रीम करना भी देखें.
response.streaming.enabled false

डिफ़ॉल्ट तौर पर (false), एचटीटीपी रिस्पॉन्स के पेलोड को बफ़र में पढ़ा जाता है. साथ ही, पेलोड पर काम करने वाली नीतियां, उम्मीद के मुताबिक काम करती हैं. अगर पेलोड, बफ़र के साइज़ (10 एमबी) से बड़े हैं, तो इस एट्रिब्यूट को true पर सेट किया जा सकता है. जब true होता है, तो एचटीटीपी रिस्पॉन्स के पेलोड को बफ़र में नहीं पढ़ा जाता. उन्हें ProxyEndpoint के रिस्पॉन्स फ़्लो पर, बिना किसी बदलाव के स्ट्रीम किया जाता है. इस मामले में, TargetEndpoint के रिस्पॉन्स फ़्लो में पेलोड पर काम करने वाली सभी नीतियां बायपास हो जाती हैं. अनुरोधों और जवाबों को स्ट्रीम करना भी देखें Streaming requests and responses.
success.codes लागू नहीं

डिफ़ॉल्ट तौर पर, Apigee Edge, एचटीटीपी कोड 4XX या 5XX को गड़बड़ी के तौर पर मानता है. साथ ही, एचटीटीपी कोड 1XX, 2XX, 3XX को सफल कोड के तौर पर मानता है. इस प्रॉपर्टी की मदद से, सफल कोड को साफ़ तौर पर तय किया जा सकता है. उदाहरण के लिए, 2XX, 1XX, 505 का मतलब है कि 100, 200, और 505 एचटीटीपी रिस्पॉन्स कोड को सफल माना जाएगा.

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

<Property name="success.codes">1XX,2XX,3XX,400</Property>

अगर आपको सिर्फ़ एचटीटीपी कोड 400 को सफल कोड के तौर पर मानना है, तो प्रॉपर्टी को इस तरह सेट करें:

<Property name="success.codes">400</Property>

एचटीटीपी कोड 400 को सिर्फ़ सफल कोड के तौर पर सेट करने पर, कोड 1XX, 2XX, और 3XX को गड़बड़ी के तौर पर माना जाता है.
compression.algorithm लागू नहीं डिफ़ॉल्ट तौर पर, Apigee Edge, क्लाइंट के अनुरोध में इस्तेमाल किए गए कंप्रेस करने के तरीके का इस्तेमाल करके, टारगेट को अनुरोध फ़ॉरवर्ड करता है. उदाहरण के लिए, अगर क्लाइंट से gzip कंप्रेस करने के तरीके का इस्तेमाल करके अनुरोध मिलता है, तो Apigee Edge, gzip कंप्रेस करने के तरीके का इस्तेमाल करके टारगेट को अनुरोध फ़ॉरवर्ड करता है. अगर टारगेट से मिले रिस्पॉन्स में डिफ़्लेट का इस्तेमाल किया जाता है, तो Apigee Edge, डिफ़्लेट का इस्तेमाल करके क्लाइंट को रिस्पॉन्स फ़ॉरवर्ड करता है. इन वैल्यू का इस्तेमाल किया जा सकता है:
  • gzip: मैसेज हमेशा gzip कंप्रेस करने के तरीके का इस्तेमाल करके भेजें
  • deflate: मैसेज हमेशा डिफ़्लेट कंप्रेस करने के तरीके का इस्तेमाल करके भेजें
  • none: मैसेज हमेशा बिना कंप्रेस किए भेजें

यह भी देखें: क्या Apigee, GZIP/डिफ़्लेट कंप्रेस करने के तरीके का इस्तेमाल करके कंप्रेस/डिकंप्रेस करने की सुविधा देता है?
request.retain.headers.
enabled		 true डिफ़ॉल्ट तौर पर, Apigee Edge, आउटबाउंड मैसेज में मौजूद सभी एचटीटीपी हेडर को हमेशा बनाए रखता है. जब इसे true पर सेट किया जाता है, तो इनबाउंड अनुरोध में मौजूद सभी एचटीटीपी हेडर, आउटबाउंड अनुरोध पर सेट हो जाते हैं.
request.retain.headers लागू नहीं अनुरोध में मौजूद उन खास एचटीटीपी हेडर के बारे में बताता है जिन्हें टारगेट सेवा को भेजे जाने वाले आउटबाउंड अनुरोध पर सेट किया जाना चाहिए. उदाहरण के लिए, पासथ्रू करने के लिए, User-Agent हेडर की वैल्यू को request.retain.headers पर सेट करेंUser-Agent. एक से ज़्यादा एचटीटीपी हेडर को कॉमा लगाकर अलग की गई लिस्ट के तौर पर तय किया जाता है. उदाहरण के लिए, User-Agent,Referer,Accept-Language. यह प्रॉपर्टी, request.retain.headers.enabled को बदल देती है. अगर request.retain.headers.enabled को false पर सेट किया जाता है, तब भी request.retain.headers प्रॉपर्टी में तय किए गए सभी हेडर, आउटबाउंड मैसेज पर सेट हो जाते हैं.
response.retain.headers.
enabled		 true डिफ़ॉल्ट तौर पर, Apigee Edge, आउटबाउंड मैसेज में मौजूद सभी एचटीटीपी हेडर को हमेशा बनाए रखता है. जब इसे true पर सेट किया जाता है, तो टारगेट सेवा से मिले इनबाउंड रिस्पॉन्स में मौजूद सभी एचटीटीपी हेडर, ProxyEndpoint को पास किए जाने से पहले, आउटबाउंड रिस्पॉन्स पर सेट हो जाते हैं.
response.retain.headers लागू नहीं रिस्पॉन्स में मौजूद उन खास एचटीटीपी हेडर के बारे में बताता है जिन्हें ProxyEndpoint को पास किए जाने से पहले, आउटबाउंड रिस्पॉन्स पर सेट किया जाना चाहिए. उदाहरण के लिए, पासथ्रू करने के लिए Expires हेडर, response.retain.headers की वैल्यू को Expires पर सेट करें. एक से ज़्यादा एचटीटीपी हेडर को कॉमा-सेपरेटेड लिस्ट के तौर पर तय किया जाता है. उदाहरण के लिए, Expires,Set-Cookie. यह प्रॉपर्टी, response.retain.headers.enabled को बदल देती है. अगर response.retain.headers.enabled को false पर सेट किया जाता है, तब भी हेडर जो response.retain.headers प्रॉपर्टी में तय किए गए हैं, आउटबाउंड मैसेज पर सेट हो जाते हैं.
retain.queryparams.
enabled		 true डिफ़ॉल्ट तौर पर, Apigee Edge, आउटबाउंड अनुरोधों में मौजूद सभी क्वेरी पैरामीटर को हमेशा बनाए रखता है. जब इसे true पर सेट किया जाता है, तो इनबाउंड अनुरोध में मौजूद सभी क्वेरी पैरामीटर, टारगेट सेवा को भेजे जाने वाले आउटबाउंड अनुरोध पर सेट हो जाते हैं.
retain.queryparams लागू नहीं आउटबाउंड अनुरोध पर सेट किए जाने वाले खास क्वेरी पैरामीटर तय करता है. उदाहरण के लिए, अनुरोध मैसेज में मौजूद क्वेरी पैरामीटर apikey को शामिल करने के लिए, retain.queryparams को apikey पर सेट करें. एक से ज़्यादा क्वेरी पैरामीटर को कॉमा लगाकर अलग की गई लिस्ट के तौर पर तय किया जाता है. उदाहरण के लिए, apikey,environment. यह प्रॉपर्टी, retain.queryparams.enabled को बदल देती है.

ProxyEndpoint की ट्रांसपोर्ट प्रॉपर्टी

ProxyEndpoint के HTTPTargetConnection एलिमेंट, एचटीटीपी ट्रांसपोर्ट की प्रॉपर्टी का सेट तय करते हैं. ट्रांसपोर्ट-लेवल के कॉन्फ़िगरेशन सेट करने के लिए, इन प्रॉपर्टी का इस्तेमाल किया जा सकता है.

प्रॉपर्टी को ProxyEndpoint के HTTPProxyConnection एलिमेंट पर, इस तरह सेट किया जाता है:

<ProxyEndpoint name="default">
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <Properties>
      <Property name="request.streaming.enabled">true</Property>
    </Properties>
    <VirtualHost>default</VirtualHost>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
</ProxyEndpoint>

वर्चुअल होस्ट के बारे में ज़्यादा जानने के लिए, वर्चुअल होस्ट के बारे में जानकारी देखें.

ProxyEndpoint की ट्रांसपोर्ट प्रॉपर्टी की खास जानकारी

प्रॉपर्टी का नाम डिफ़ॉल्ट मान ब्यौरा
X-Forwarded-For false जब इसे true पर सेट किया जाता है, तो वर्चुअल होस्ट का आईपी पता, एचटीटीपी X-Forwarded-For हेडर की वैल्यू के तौर पर, आउटबाउंड अनुरोध में जोड़ा जाता है.
request.streaming.
enabled		 false डिफ़ॉल्ट तौर पर (false), एचटीटीपी अनुरोध के पेलोड को बफ़र में पढ़ा जाता है. साथ ही, पेलोड पर काम करने वाली नीतियां, उम्मीद के मुताबिक काम करती हैं. अगर पेलोड, बफ़र के साइज़ (10 एमबी) से बड़े हैं, तो इस एट्रिब्यूट को true पर सेट किया जा सकता है. जब true होता है, तो एचटीटीपी अनुरोध के पेलोड को बफ़र में नहीं पढ़ा जाता. उन्हें TargetEndpoint के अनुरोध फ़्लो पर, बिना किसी बदलाव के स्ट्रीम किया जाता है. इस मामले में, ProxyEndpoint के अनुरोध फ़्लो में पेलोड पर काम करने वाली सभी नीतियां बायपास हो जाती हैं. अनुरोधों और जवाबों को स्ट्रीम करना भी देखें.
response.streaming.
enabled		 false डिफ़ॉल्ट तौर पर (false), एचटीटीपी रिस्पॉन्स के पेलोड को बफ़र में पढ़ा जाता है. साथ ही, पेलोड पर काम करने वाली नीतियां, उम्मीद के मुताबिक काम करती हैं. अगर पेलोड, बफ़र के साइज़ (10 एमबी) से बड़े हैं, तो इस एट्रिब्यूट को true पर सेट किया जा सकता है. जब true होता है, तो एचटीटीपी रिस्पॉन्स के पेलोड को बफ़र में नहीं पढ़ा जाता. उन्हें क्लाइंट को, बिना किसी बदलाव के स्ट्रीम किया जाता है. इस मामले में, ProxyEndpoint के रिस्पॉन्स फ़्लो में पेलोड पर काम करने वाली सभी नीतियां बायपास हो जाती हैं. अनुरोधों और जवाबों को स्ट्रीम करना भी देखें.
compression.algorithm लागू नहीं

डिफ़ॉल्ट तौर पर, Apigee Edge, मिले किसी भी मैसेज के लिए सेट किए गए कंप्रेस करने के तरीके का इस्तेमाल करता है. उदाहरण के लिए, अगर कोई क्लाइंट gzip कंप्रेस करने के तरीके का इस्तेमाल करके अनुरोध सबमिट करता है, तो Apigee Edge gzip कंप्रेस करने के तरीके का इस्तेमाल करके टारगेट को अनुरोध फ़ॉरवर्ड करता है. TargetEndpoint या ProxyEndpoint पर इस प्रॉपर्टी को सेट करके, कंप्रेस करने के एल्गोरिदम को साफ़ तौर पर लागू किया जा सकता है. इन वैल्यू का इस्तेमाल किया जा सकता है:

  • gzip: मैसेज हमेशा gzip कंप्रेस करने के तरीके का इस्तेमाल करके भेजें
  • deflate: मैसेज हमेशा डिफ़्लेट कंप्रेस करने के तरीके का इस्तेमाल करके भेजें
  • none: मैसेज हमेशा बिना कंप्रेस किए भेजें

यह भी देखें: क्या Apigee, GZIP/डिफ़्लेट कंप्रेस करने के तरीके का इस्तेमाल करके कंप्रेस/डिकंप्रेस करने की सुविधा देता है?
api.timeout लागू नहीं

एपीआई की अलग-अलग प्रॉक्सी के लिए टाइमआउट कॉन्फ़िगर करना

एपीआई की प्रॉक्सी को कॉन्फ़िगर किया जा सकता है. यहां तक कि स्ट्रीम करने की सुविधा चालू करने वाली प्रॉक्सी को भी. ऐसा करने पर, वे तय समय के बाद 504 Gateway Timeout स्टेटस के साथ टाइम आउट हो जाती हैं. इसका मुख्य इस्तेमाल उन ग्राहकों के लिए है जिनकी एपीआई प्रॉक्सी को एक्ज़ीक्यूट होने में ज़्यादा समय लगता है. उदाहरण के लिए, मान लें कि आपको कुछ प्रॉक्सी को तीन मिनट में टाइम आउट करना है. api.timeout का इस्तेमाल इस तरह किया जाता है.

  1. सबसे पहले, लोड बैलेंसर, राउटर, और मैसेज प्रोसेसर को तीन मिनट बाद टाइम आउट होने के लिए कॉन्फ़िगर करें.
  2. इसके बाद, काम की प्रॉक्सी को तीन मिनट में टाइम आउट होने के लिए कॉन्फ़िगर करें. वैल्यू को मिलीसेकंड में तय करें. उदाहरण के लिए: <Property name="api.timeout">180000</Property>
  3. हालांकि, ध्यान दें कि सिस्टम के टाइमआउट को बढ़ाने से परफ़ॉर्मेंस से जुड़ी समस्याएं हो सकती हैं. ऐसा इसलिए, क्योंकि api.timeout सेटिंग के बिना सभी प्रॉक्सी, लोड बैलेंसर, राउटर, और मैसेज प्रोसेसर के नए और ज़्यादा टाइमआउट का इस्तेमाल करती हैं. इसलिए, एपीआई की उन अन्य प्रॉक्सी को कम टाइमआउट का इस्तेमाल करने के लिए कॉन्फ़िगर करें जिन्हें ज़्यादा टाइमआउट की ज़रूरत नहीं है. उदाहरण के लिए, यहां दी गई सेटिंग से, एपीआई की प्रॉक्सी एक मिनट बाद टाइम आउट हो जाएगी:
    <Property name="api.timeout">60000</Property>

इस प्रॉपर्टी को वैरिएबल के साथ सेट नहीं किया जा सकता.

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

ज़्यादा जानकारी के लिए, Edge के लिए io.timeout.millis और api.timeout सेट करना देखें.

Edge के लिए io.timeout.millis और api.timeout सेट करना

Edge पर, io.timeout.millis और api.timeout की कार्रवाई एक-दूसरे से जुड़ी होती है. एपीआई की प्रॉक्सी के हर अनुरोध पर:

  1. राउटर, मैसेज प्रोसेसर को अपनी टाइमआउट वैल्यू भेजता है. राउटर की टाइमआउट वैल्यू, अनुरोध को हैंडल करने वाले वर्चुअल होस्ट की ओर से सेट की गई proxy_read_timeout की वैल्यू होती है. इसके अलावा, डिफ़ॉल्ट टाइमआउट वैल्यू 57 सेकंड भी हो सकती है.
  2. इसके बाद, मैसेज प्रोसेसर, api.timeout सेट करता है:
    1. अगर प्रॉक्सी के लेवल पर api.timeout सेट नहीं किया गया है, तो इसे राउटर के टाइमआउट पर सेट करें.
    2. अगर api.timeout प्रॉक्सी के लेवल पर सेट किया गया है, तो इसे मैसेज प्रोसेसर पर, राउटर के टाइमआउट या api.timeout की वैल्यू में से कम वैल्यू पर सेट करें.

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

    एपीआई की प्रॉक्सी में मौजूद हर नीति के एक्ज़ीक्यूट होने के बाद, या टारगेट एंडपॉइंट को अनुरोध भेजने से पहले, मैसेज प्रोसेसर, (api.timeout - अनुरोध शुरू होने से लेकर अब तक का समय) की गणना करता है. अगर वैल्यू शून्य से कम है, तो अनुरोध को हैंडल करने में लगने वाला ज़्यादा से ज़्यादा समय खत्म हो गया है. साथ ही, मैसेज प्रोसेसर 504 दिखाता है.

  4. io.timeout.millis की वैल्यू से, उस ज़्यादा से ज़्यादा समय के बारे में पता चलता है जो टारगेट एंडपॉइंट को जवाब देने में लगता है.

    टारगेट एंडपॉइंट से कनेक्ट होने से पहले, मैसेज प्रोसेसर, (api.timeout - अनुरोध शुरू होने से लेकर अब तक का समय) और io.timeout.millis में से कम वैल्यू तय करता है. इसके बाद, io.timeout.millis को उस वैल्यू पर सेट करता है.

    • अगर एचटीटीपी अनुरोध लिखते समय टाइमआउट होता है, तो 408, Request Timeout दिखाया जाता है.
    • अगर एचटीटीपी रिस्पॉन्स पढ़ते समय टाइमआउट होता है, तो 504, Gateway Timeout दिखाया जाता है.

Node.js ऐप्लिकेशन के लिए ScriptTarget के बारे में जानकारी

ScriptTarget एलिमेंट का इस्तेमाल, Node.js ऐप्लिकेशन को अपनी प्रॉक्सी में इंटिग्रेट करने के लिए किया जाता है. Node.js और ScriptTarget का इस्तेमाल करने के बारे में जानकारी के लिए, ये लेख पढ़ें:

होस्ट किए गए टारगेट एंडपॉइंट के बारे में जानकारी

खाली <HostedTarget/> टैग, Edge को यह निर्देश देता है कि वह अपने टारगेट के तौर पर, Hosted Targets एनवायरमेंट में डिप्लॉय किए गए Node.js ऐप्लिकेशन का इस्तेमाल करे. ज़्यादा जानकारी के लिए, होस्ट किए गए टारगेट की खास जानकारी देखें.