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

आपको Apigee Edge दस्तावेज़ दिख रहा है.
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है इस पेज पर जाएं Apigee X दस्तावेज़. जानकारी

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

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

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

प्रॉपर्टी, 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 स्टेटस कोड दिखाता है टाइम आउट हो जाता है. कुछ मामलों में, LoadBalancer के दौरान एचटीटीपी 504 स्टेटस कोड दिख सकता है का इस्तेमाल TargetServer की परिभाषा में किया जाता है और एक टाइम आउट हो जाता है.

io.timeout.millis 55000

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

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

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

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

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

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

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

&lt;Property name="सफल.codes">1XX,2XX,3XX,400</प्रॉपर्टी>

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

&lt;Property name="सफल.codes">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 तक, टारगेट से इनबाउंड रिस्पॉन्स पर मौजूद सभी एचटीटीपी हेडर सेवा, प्रॉक्सीएंडपॉइंट को पास किए जाने से पहले आउटबाउंड रिस्पॉन्स पर सेट हो जाती है.
response.retain.headers लागू नहीं रिस्पॉन्स में मौजूद उन एचटीटीपी हेडर के बारे में बताता है जिन्हें आउटबाउंड पर सेट किया जाना चाहिए इसका जवाब देना होगा. उदाहरण के लिए, पासथ्रू 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 के अनुरोध फ़्लो के तौर पर स्ट्रीम किया जाता है. इस स्थिति में, जो भी नीतियां काम करती हैं पर लागू होती है. अनुरोध और जवाब स्ट्रीम करना भी देखें.
response.streaming.
enabled		 false डिफ़ॉल्ट रूप से (false), एचटीटीपी रिस्पॉन्स पेलोड बफ़र में पढ़े जाते हैं. साथ ही, इन नीतियों के तहत पेलोड पर उम्मीद के मुताबिक काम किया जा सकता है. ऐसे मामलों में जहां पेलोड से ज़्यादा बफ़र साइज़ (10 एमबी) है, तो इसे सेट किया जा सकता है एट्रिब्यूट की वैल्यू true सबमिट करें. true होने पर, एचटीटीपी रिस्पॉन्स पेलोड को बफ़र में नहीं पढ़ा जाता है; वे हैं इसे क्लाइंट ऐप्लिकेशन के तौर पर स्ट्रीम किया जाता है. इस मामले में, ऐसी कोई भी नीति जो ProxyEndpoint रिस्पॉन्स फ़्लो को बायपास किया जाता है. अनुरोध और जवाब स्ट्रीम करना भी देखें.
compression.algorithm लागू नहीं

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

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

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

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

आपके पास एपीआई प्रॉक्सी कॉन्फ़िगर करने का विकल्प होता है. इनकी मदद से, स्ट्रीमिंग चालू की गई, 504 Gateway Timeout स्थिति के साथ किसी खास समय के बाद समय खत्म करने के लिए. मुख्य इस्तेमाल का उदाहरण उन ग्राहकों के लिए है जिनके पास एपीआई प्रॉक्सी है जिन्हें एक्ज़ीक्यूट करने में ज़्यादा समय लगता है. उदाहरण के लिए, मान लीजिए कि आपको 3 बजे टाइम आउट करने के लिए खास प्रॉक्सी की ज़रूरत है मिनट. 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.milis और 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 को टारगेट करने के लिए इस्तेमाल करता है ऐसे ऐप्लिकेशन जो होस्ट किए गए टारगेट एनवायरमेंट में डिप्लॉय किए जाते हैं. जानकारी के लिए, यह देखें होस्ट किए गए टारगेट की खास जानकारी.