এন্ডপয়েন্ট প্রপার্টি রেফারেন্স

আপনি Apigee Edge-এর ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশন
.info- তে যান।

এই টপিকে সেইসব ট্রান্সপোর্ট প্রপার্টি বর্ণনা করা হয়েছে, যা মেসেজিং এবং কানেকশনের আচরণ নিয়ন্ত্রণ করার জন্য TargetEndpoint ও ProxyEndpoint কনফিগারেশনে সেট করা যায়। TargetEndpoint ও ProxyEndpoint কনফিগারেশনের সম্পূর্ণ বিবরণের জন্য, API প্রক্সি কনফিগারেশন রেফারেন্স দেখুন।

টার্গেটএন্ডপয়েন্ট পরিবহন বৈশিষ্ট্য

TargetEndpoint কনফিগারেশনে থাকা HTTPTargetConnection এলিমেন্টটি এক সেট HTTP ট্রান্সপোর্ট প্রোপার্টি নির্ধারণ করে। আপনি এই প্রোপার্টিগুলো ব্যবহার করে ট্রান্সপোর্ট-স্তরের কনফিগারেশন সেট করতে পারেন।

নিচে দেখানো অনুযায়ী 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 একটি HTTP 503 স্ট্যাটাস কোড রিটার্ন করে। কিছু ক্ষেত্রে, যখন TargetServer ডেফিনিশনে LoadBalancer ব্যবহার করা হয় এবং টাইমআউট ঘটে, তখন একটি HTTP 504 স্ট্যাটাস কোড রিটার্ন হতে পারে।

io.timeout.millis 55000

যদি নির্দিষ্ট সংখ্যক মিলিসেকেন্ড ধরে পড়ার মতো কোনো ডেটা না থাকে, অথবা সকেটটি নির্দিষ্ট সংখ্যক মিলিসেকেন্ড ধরে ডেটা লেখার জন্য প্রস্তুত না থাকে, তাহলে লেনদেনটিকে টাইমআউট হিসেবে গণ্য করা হয়।

  • HTTP অনুরোধ লেখার সময় টাইমআউট হলে, 408, Request Timeout ফেরত দেওয়া হয়।
  • HTTP রেসপন্স পড়ার সময় টাইমআউট হলে 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 ফাইলে প্রক্সি কনফিগারেশন নির্দিষ্ট করা থাকে (শুধুমাত্র অন-প্রিমিসেস ডেপ্লয়মেন্টের ক্ষেত্রে), তাহলে টার্গেট কানেকশনগুলো নির্দিষ্ট টানেলটি ব্যবহার করার জন্য সেট করা হয়। যদি টার্গেট TLS/SSL ব্যবহার করে, তাহলে এই প্রপার্টিটি উপেক্ষা করা হয় এবং মেসেজটি সর্বদা একটি টানেলের মাধ্যমে পাঠানো হয়।
enable.method.override false নির্দিষ্ট HTTP মেথডের জন্য, টার্গেট সার্ভিসে পাঠানো আউটবাউন্ড রিকোয়েস্টে একটি X-HTTP-Method-Override হেডার সেট করে। উদাহরণস্বরূপ, <Property name="GET.override.method">POST</Property>
*.override.method প্রযোজ্য নয় নির্দিষ্ট HTTP মেথডের জন্য, বহির্গামী অনুরোধে একটি X-HTTP-Method-Override হেডার সেট করে। উদাহরণস্বরূপ, <Property name="GET.override.method">POST</Property>
request.streaming.enabled false

ডিফল্টরূপে ( false ), HTTP রিকোয়েস্ট পেলোডগুলো একটি বাফারে লোড করা হয় এবং যে পলিসিগুলো পেলোডের উপর কাজ করতে পারে, সেগুলো প্রত্যাশিতভাবেই কাজ করে। যেসব ক্ষেত্রে পেলোডগুলো বাফারের আকারের (১০ এমবি) চেয়ে বড় হয়, আপনি এই অ্যাট্রিবিউটটি true ) সেট করতে পারেন। true হলে, HTTP রিকোয়েস্ট পেলোডগুলো কোনো বাফারে লোড করা হয় না; সেগুলোকে সরাসরি টার্গেট এন্ডপয়েন্টে স্ট্রিম করা হয়। এই ক্ষেত্রে, টার্গেটএন্ডপয়েন্ট রিকোয়েস্ট ফ্লোতে পেলোডের উপর কাজ করে এমন যেকোনো পলিসি বাইপাস হয়ে যায়। আরও দেখুন স্ট্রিমিং রিকোয়েস্ট এবং রেসপন্স

response.streaming.enabled false

ডিফল্টরূপে ( false ), HTTP রেসপন্স পেলোডগুলো একটি বাফারে লোড করা হয় এবং যে পলিসিগুলো পেলোডের উপর কাজ করতে পারে, সেগুলো প্রত্যাশিতভাবেই কাজ করে। যেসব ক্ষেত্রে পেলোডগুলো বাফারের আকারের (১০ এমবি) চেয়ে বড় হয়, আপনি এই অ্যাট্রিবিউটটি true ) সেট করতে পারেন। true হলে, HTTP রেসপন্স পেলোডগুলো কোনো বাফারে লোড করা হয় না; সেগুলোকে সরাসরি ProxyEndpoint রেসপন্স ফ্লো-তে স্ট্রিম করা হয়। এই ক্ষেত্রে, TargetEndpoint রেসপন্স ফ্লো-তে পেলোডের উপর কাজ করে এমন যেকোনো পলিসি বাইপাস হয়ে যায়। আরও দেখুন স্ট্রিমিং রিকোয়েস্ট এবং রেসপন্স

success.codes প্রযোজ্য নয়

ডিফল্টরূপে, Apigee Edge HTTP কোড 4XX বা 5XX কে ত্রুটি হিসেবে এবং HTTP কোড 1XX , 2XX , 3XX সফল হিসেবে গণ্য করে। এই প্রপার্টিটি সফল কোডগুলোর সুস্পষ্ট সংজ্ঞা নির্ধারণ করতে সক্ষম করে; উদাহরণস্বরূপ, 2XX, 1XX, 505 যেকোনো 100 , 200 এবং 505 HTTP রেসপন্স কোডকে সফল হিসেবে গণ্য করে।

এই প্রপার্টিটি সেট করলে ডিফল্ট মানগুলো ওভাররাইট হয়ে যায়। সুতরাং, আপনি যদি ডিফল্ট সফল কোডের তালিকায় HTTP কোড 400 যোগ করতে চান, তাহলে এই প্রপার্টিটি এভাবে সেট করুন:

<সম্পত্তির নাম="success.codes">1XX,2XX,3XX,400</সম্পত্তি>

যদি আপনি চান যে শুধুমাত্র HTTP কোড 400 একটি সফল কোড হিসেবে গণ্য হোক, তাহলে প্রপার্টিটি এভাবে সেট করুন:

<সম্পত্তির নাম="success.codes">400</সম্পত্তি>

HTTP কোড 400 কে একমাত্র সফলতার কোড হিসেবে নির্ধারণ করার ফলে, 1XX , 2XX এবং 3XX কোডগুলোকে ব্যর্থ হিসেবে গণ্য করা হয়।

compression.algorithm প্রযোজ্য নয় ডিফল্টরূপে, Apigee Edge ক্লায়েন্ট অনুরোধের মতো একই কম্প্রেশন টাইপ ব্যবহার করে টার্গেটে অনুরোধ ফরোয়ার্ড করে। উদাহরণস্বরূপ, যদি ক্লায়েন্ট থেকে অনুরোধটি gzip কম্প্রেশন ব্যবহার করে আসে, তাহলে Apigee Edge অনুরোধটি gzip কম্প্রেশন ব্যবহার করে টার্গেটে ফরোয়ার্ড করে। যদি টার্গেট থেকে প্রাপ্ত প্রতিক্রিয়াটি deflate ব্যবহার করে, তাহলে Apigee Edge প্রতিক্রিয়াটি deflate ব্যবহার করে ক্লায়েন্টের কাছে ফরোয়ার্ড করে। সমর্থিত মানগুলি হলো:
  • gzip: সর্বদা gzip কম্প্রেশন ব্যবহার করে বার্তা পাঠান
  • ডিফ্লেট: সর্বদা ডিফ্লেট কম্প্রেশন ব্যবহার করে বার্তা পাঠান
  • কোনোটিই নয়: সর্বদা কোনো কম্প্রেশন ছাড়াই বার্তা পাঠান

আরও দেখুন: Apigee কি GZIP/deflate কম্প্রেশনের মাধ্যমে কম্প্রেশন/ডি-কম্প্রেশন সমর্থন করে?

request.retain.headers.
enabled
true ডিফল্টরূপে, Apigee Edge বহির্গামী বার্তাগুলিতে সর্বদা সমস্ত HTTP হেডার ধরে রাখে। যখন এটিকে true তে সেট করা হয়, তখন আগত অনুরোধে উপস্থিত সমস্ত HTTP হেডার বহির্গামী অনুরোধেও সেট করা হয়।
request.retain.headers প্রযোজ্য নয় এটি রিকোয়েস্ট থেকে নির্দিষ্ট HTTP হেডারগুলো নির্ধারণ করে, যা টার্গেট সার্ভিসে পাঠানো আউটবাউন্ড রিকোয়েস্টে সেট করা উচিত। উদাহরণস্বরূপ, User-Agent হেডারটি পাসথ্রু করতে, request.retain.headers এর ভ্যালু User-Agent এ সেট করুন। একাধিক HTTP হেডার কমা দিয়ে আলাদা করা একটি তালিকা হিসেবে উল্লেখ করা হয়, যেমন, User-Agent,Referer,Accept-Language । এই প্রপার্টিটি request.retain.headers.enabled কে ওভাররাইড করে। যদি request.retain.headers.enabled false এ সেট করা হয়, তাহলেও request.retain.headers প্রপার্টিতে উল্লেখিত যেকোনো হেডার আউটবাউন্ড মেসেজে সেট হয়ে যাবে।
response.retain.headers.
enabled
true ডিফল্টরূপে, Apigee Edge বহির্গামী বার্তাগুলিতে সর্বদা সমস্ত HTTP হেডার ধরে রাখে। যখন এটিকে ' true তে সেট করা হয়, তখন টার্গেট পরিষেবা থেকে আসা ইনবাউন্ড রেসপন্সে উপস্থিত সমস্ত HTTP হেডার, ProxyEndpoint-এ পাঠানোর আগে আউটবাউন্ড রেসপন্সেও সেট করা হয়।
response.retain.headers প্রযোজ্য নয় এটি রেসপন্স থেকে নির্দিষ্ট HTTP হেডারগুলো নির্ধারণ করে, যেগুলো ProxyEndpoint-এ পাঠানোর আগে আউটবাউন্ড রেসপন্সে সেট করা উচিত। উদাহরণস্বরূপ, Expires হেডারটি পাসথ্রু করতে, response.retain.headers এর মান Expires এ সেট করুন। একাধিক HTTP হেডার কমা দিয়ে আলাদা করা একটি তালিকা হিসেবে উল্লেখ করা হয়, যেমন, 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 HTTPTargetConnection এলিমেন্টগুলো এক সেট HTTP ট্রান্সপোর্ট প্রোপার্টি নির্ধারণ করে। এই প্রোপার্টিগুলো ট্রান্সপোর্ট-স্তরের কনফিগারেশন সেট করতে ব্যবহার করা যেতে পারে।

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>

ভার্চুয়াল হোস্ট সম্পর্কে আরও জানতে, ‘ভার্চুয়াল হোস্ট সম্পর্কে’ দেখুন।

প্রক্সিএন্ডপয়েন্ট পরিবহন বৈশিষ্ট্য স্পেসিফিকেশন

সম্পত্তির নাম ডিফল্ট মান বর্ণনা
X-Forwarded-For false যখন ' true সেট করা হয়, তখন ভার্চুয়াল হোস্টের আইপি অ্যাড্রেসটি আউটবাউন্ড রিকোয়েস্টে HTTP X-Forwarded-For হেডারের ভ্যালু হিসেবে যুক্ত করা হয়।
request.streaming.
enabled
false ডিফল্টরূপে ( false ), HTTP রিকোয়েস্ট পেলোডগুলো একটি বাফারে লোড করা হয় এবং যে পলিসিগুলো পেলোডের উপর কাজ করতে পারে, সেগুলো প্রত্যাশিতভাবেই কাজ করে। যেসব ক্ষেত্রে পেলোডগুলো বাফারের আকারের (১০ এমবি) চেয়ে বড় হয়, আপনি এই অ্যাট্রিবিউটটি ট্রু ( true ) সেট করতে পারেন। true হলে, HTTP রিকোয়েস্ট পেলোডগুলো কোনো বাফারে লোড করা হয় না; সেগুলোকে সরাসরি টার্গেটএন্ডপয়েন্ট (TargetEndpoint) রিকোয়েস্ট ফ্লোতে স্ট্রিম করা হয়। এই ক্ষেত্রে, প্রক্সিএন্ডপয়েন্ট (ProxyEndpoint) রিকোয়েস্ট ফ্লোতে পেলোডের উপর কাজ করে এমন যেকোনো পলিসি বাইপাস হয়ে যায়। আরও দেখুন স্ট্রিমিং রিকোয়েস্ট এবং রেসপন্স
response.streaming.
enabled
false ডিফল্টরূপে ( false ), HTTP রেসপন্স পেলোডগুলো একটি বাফারে লোড করা হয় এবং যে পলিসিগুলো পেলোডের উপর কাজ করতে পারে, সেগুলো প্রত্যাশিতভাবেই কাজ করে। যেসব ক্ষেত্রে পেলোডগুলো বাফারের আকারের (১০ এমবি) চেয়ে বড় হয়, আপনি এই অ্যাট্রিবিউটটি true ) সেট করতে পারেন। true হলে, HTTP রেসপন্স পেলোডগুলো কোনো বাফারে লোড করা হয় না; সেগুলো সরাসরি ক্লায়েন্টের কাছে স্ট্রিম করা হয়। এই ক্ষেত্রে, ProxyEndpoint রেসপন্স ফ্লোতে পেলোডের উপর কাজ করে এমন যেকোনো পলিসি বাইপাস হয়ে যায়। আরও দেখুন স্ট্রিমিং রিকোয়েস্ট এবং রেসপন্স
compression.algorithm প্রযোজ্য নয়

ডিফল্টরূপে, Apigee Edge প্রাপ্ত যেকোনো বার্তার জন্য সেট করা কম্প্রেশন টাইপ অনুসরণ করে। উদাহরণস্বরূপ, যখন কোনো ক্লায়েন্ট gzip কম্প্রেশন ব্যবহার করে একটি অনুরোধ জমা দেয়, তখন Apigee Edge অনুরোধটি gzip কম্প্রেশন ব্যবহার করে টার্গেটে ফরোয়ার্ড করে। আপনি TargetEndpoint বা ProxyEndpoint-এ এই প্রপার্টিটি সেট করার মাধ্যমে কম্প্রেশন অ্যালগরিদমগুলো স্পষ্টভাবে প্রয়োগ করার জন্য কনফিগার করতে পারেন। সমর্থিত মানগুলো হলো:

  • gzip: সর্বদা gzip কম্প্রেশন ব্যবহার করে বার্তা পাঠান
  • ডিফ্লেট: সর্বদা ডিফ্লেট কম্প্রেশন ব্যবহার করে বার্তা পাঠান
  • কোনোটিই নয়: সর্বদা কোনো কম্প্রেশন ছাড়াই বার্তা পাঠান

আরও দেখুন: 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 টাইমআউট পরিবর্তন করতে পারেন না, তারা একটি API প্রক্সি টাইমআউটও কনফিগার করতে পারেন, তবে শর্ত হলো সেই টাইমআউটটি অবশ্যই Edge মেসেজ প্রসেসরের স্ট্যান্ডার্ড ৫৭ সেকেন্ডের টাইমআউটের চেয়ে কম হতে হবে।

আরও তথ্যের জন্য Edge-এর io.timeout.millis এবং api.timeout সেট করা দেখুন।

Edge-এর জন্য io.timeout.millis এবং api.timeout সেট করা হচ্ছে।

Edge-এ, io.timeout.millis এবং api.timeout এর কার্যক্রম পরস্পর সম্পর্কিত। একটি API প্রক্সিতে করা প্রতিটি অনুরোধের ক্ষেত্রে:

  1. রাউটার তার টাইমআউট মান মেসেজ প্রসেসরের কাছে পাঠায়। রাউটারের টাইমআউট মানটি হয় অনুরোধটি পরিচালনাকারী ভার্চুয়াল হোস্ট দ্বারা সেট করা proxy_read_timeout এর মান, অথবা ৫৭ সেকেন্ডের ডিফল্ট টাইমআউট মান।
  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 কে সেই মানে সেট করে দেয়।

    • HTTP অনুরোধ লেখার সময় টাইমআউট হলে, 408, Request Timeout ফেরত দেওয়া হয়।
    • HTTP রেসপন্স পড়ার সময় টাইমআউট হলে 504, Gateway Timeout রিটার্ন করা হয়।

Node.js অ্যাপ্লিকেশনের জন্য ScriptTarget সম্পর্কে

আপনার প্রক্সিতে একটি Node.js অ্যাপ্লিকেশন সংহত করতে ScriptTarget এলিমেন্টটি ব্যবহৃত হয়। Node.js এবং ScriptTarget ব্যবহারের তথ্যের জন্য দেখুন:

HostedTarget এন্ডপয়েন্ট সম্পর্কে

একটি খালি <HostedTarget/> ট্যাগ Edge-কে নির্দেশ দেয় যে, টার্গেট হিসেবে এমন একটি Node.js অ্যাপ্লিকেশন ব্যবহার করতে হবে যা Hosted Targets এনভায়রনমেন্টে ডেপ্লয় করা আছে। বিস্তারিত জানতে, Hosted Targets overview দেখুন।