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

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

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

टारगेटएंडपॉइंट की ट्रांसपोर्ट प्रॉपर्टी

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>

टारगेटएंडपॉइंट की ट्रांसपोर्ट प्रॉपर्टी की खास बातें

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

3000

टारगेट कनेक्शन टाइम आउट. कनेक्शन टाइम आउट होने पर, Edge एक एचटीटीपी 503 स्टेटस कोड दिखाता है.
io.timeout.millis 55000

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

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

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

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

ज़्यादा जानकारी के लिए, Edge के लिए io.timeout.मिलीसेकंड और 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 (सिर्फ़ कंपनी की इमारत में) में दी गई है, तो टारगेट कनेक्शन को तय टनल का इस्तेमाल करने के लिए सेट किया जाता है. अगर टारगेट TLS/एसएसएल का इस्तेमाल करता है, तो इस प्रॉपर्टी को अनदेखा कर दिया जाता है. साथ ही, मैसेज हमेशा किसी टनल से भेजा जाता है.
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 होने पर, एचटीटीपी रिस्पॉन्स पेलोड को बफ़र में नहीं पढ़ा जाता. उन्हें प्रॉक्सीEndpoint रिस्पॉन्स फ़्लो पर स्ट्रीम किया जाता है. इस मामले में, TargetEndpoint के रिस्पॉन्स फ़्लो में पेलोड पर काम करने वाली सभी नीतियों को बायपास किया जाता है. स्ट्रीमिंग के अनुरोध और जवाब भी देखें.
success.codes लागू नहीं

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

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

<प्रॉपर्टी name="visit.codes">1XX,2XX,3XX,400</प्रॉपर्टी>

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

<प्रॉपर्टी name="सफलता.कोड">400</प्रॉपर्टी>

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

यह भी देखें: क्या Apigee, GZIP/deflate कंप्रेस करने के साथ कंप्रेशन/डी-कंप्रेस करने की सुविधा देता है?
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 पर सेट किया जाता है, तो टारगेट सेवा के इनबाउंड रिस्पॉन्स पर मौजूद सभी एचटीटीपी हेडर, प्रॉक्सीEndpoint को पास किए जाने से पहले आउटबाउंड रिस्पॉन्स पर सेट हो जाते हैं.
response.retain.headers लागू नहीं रिस्पॉन्स से मिलने वाले खास एचटीटीपी हेडर के बारे में बताता है. इस रिस्पॉन्स को प्रॉक्सीEndpoint को पास करने से पहले, आउटबाउंड रिस्पॉन्स पर सेट किया जाना चाहिए. उदाहरण के लिए, 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 को बदल देती है.

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

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

प्रॉपर्टी प्रॉक्सीEndpoint 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>

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

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

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

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

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

यह भी देखें: क्या Apigee, GZIP/deflate कंप्रेस करने के साथ कंप्रेशन/डी-कंप्रेस करने की सुविधा देता है?
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.मिलीसेकंड और api.timeout सेट करना देखें.

Edge के लिए io.timeout.milis और 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 एंडपॉइंट के बारे में

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