এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

400 খারাপ অনুরোধ - সাধারণ HTTP অনুরোধ HTTPS পোর্টে পাঠানো হয়েছে

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

লক্ষণ

ক্লায়েন্ট অ্যাপ্লিকেশনটি The plain HTTP request was sent to HTTPS port বার্তা সহ একটি HTTP 400 Bad Request প্রতিক্রিয়া পায়।

ত্রুটির বার্তা

ক্লায়েন্ট অ্যাপ্লিকেশনটি নিম্নলিখিত প্রতিক্রিয়া কোডটি পায়:

HTTP/1.1 400 Bad Request

এর পরে নিচের HTML ত্রুটির পৃষ্ঠাটি আসে:

<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
</body>
</html>

সম্ভাব্য কারণসমূহ

কারণ	বর্ণনা	সমস্যা সমাধানের নির্দেশাবলী প্রযোজ্য
TLS-কনফিগার করা ভার্চুয়াল হোস্টে HTTP অনুরোধ	ক্লায়েন্ট একটি TLS-কনফিগার করা ভার্চুয়াল হোস্টে HTTP অনুরোধ পাঠায়।	এজ পাবলিক এবং প্রাইভেট ক্লাউড ব্যবহারকারীরা
TLS-কনফিগার করা টার্গেট এন্ডপয়েন্টে HTTP অনুরোধ	টার্গেট এন্ডপয়েন্টে থাকা একটি TLS-সক্ষম ব্যাকএন্ড সার্ভারে HTTP অনুরোধ পাঠানো হয়েছে।	এজ পাবলিক এবং প্রাইভেট ক্লাউড ব্যবহারকারীরা
ভুল টার্গেট সার্ভার কনফিগারেশন	টার্গেট সার্ভারটি সুরক্ষিত পোর্ট `443` দিয়ে কনফিগার করা আছে, কিন্তু SSL সক্রিয় করা নেই।	এজ পাবলিক এবং প্রাইভেট ক্লাউড ব্যবহারকারীরা

কারণ: TLS-কনফিগার করা ভার্চুয়াল হোস্টে HTTP অনুরোধ

এই ত্রুটিটি ঘটে যখন কোনো ক্লায়েন্ট Apigee-তে একটি API-এর সাথে সংযোগ করার চেষ্টা করে এবং উল্লিখিত ভার্চুয়াল হোস্টটি SSL ব্যবহার করার জন্য কনফিগার করা থাকলেও তার পরিবর্তে একটি HTTP অনুরোধ গ্রহণ করে।

রোগ নির্ণয়

যেহেতু এই সমস্যাটি নর্থবাউন্ড এন্ডপয়েন্টে ঘটে এবং ক্লায়েন্ট অ্যাপ্লিকেশন ও রাউটারের মধ্যকার সংযোগস্থলে এপিআই অনুরোধগুলো ব্যর্থ হয়, তাই এই ত্রুটির বার্তাগুলো NGINX রাউটারের অ্যাক্সেস লগে লগ করা হয় না। ফলে, এপিআই মনিটরিং এবং ট্রেস টুলের মতো টুলগুলোতে এই অনুরোধগুলো ধরা পড়ে না।

আপনার এপিআই অনুরোধটি যাচাই করুন এবং দেখুন আপনি এমন কোনো হোস্ট অ্যালিয়াসের জন্য এইচটিটিপি অনুরোধ করছেন কি না, যা শুধুমাত্র সুরক্ষিত পোর্ট 443 এ অনুরোধ গ্রহণ করার জন্য কনফিগার করা আছে। যদি তাই হয়, তাহলে সেটাই সমস্যার কারণ।
ভুল এপিআই অনুরোধের নমুনা:
```
curl http://org-test.apigee.net:443/400-demo
```
```
<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>server</center>
</body>
</html>
```
উপরের নমুনা অনুরোধটিতে লক্ষ্য করুন যে, myorg-test.apigee.net হোস্ট অ্যালিয়াসে সুরক্ষিত পোর্ট 443 এ একটি HTTP অনুরোধ করা হয়েছে। এটাই 400 Bad Request ত্রুটির কারণ।

সমাধান

ক্লায়েন্ট HTTPs-এর পরিবর্তে HTTP ব্যবহার করছে কিনা তা আপনাকে যাচাই করতে হবে এবং নিচে দেখানো অনুযায়ী সঠিক অনুরোধটি করতে হবে:

নমুনা এপিআই অনুরোধ:

curl https://org-test.apigee.net:443/400-demo

অথবা

curl https://org-test.apigee.net/400-demo

< HTTP/1.1 200 OK
< Date: Thu, 25 Feb 2021 13:01:43 GMT
< Content-Type: text/xml;charset=UTF-8
< Content-Length: 403
< Connection: keep-alive
< Server: gunicorn/19.9.0
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Credentials: true

দ্রষ্টব্য: স্ট্যান্ডার্ড সুরক্ষিত পোর্ট 443 এর সাথে HTTPS প্রোটোকল ব্যবহার করার সময় পোর্ট নম্বরের প্রয়োজন হয় না, যেমনটি উপরের নমুনা অনুরোধে দেখানো হয়েছে।

কারণ: TLS-কনফিগার করা টার্গেট এন্ডপয়েন্টে HTTP অনুরোধ

এপিআই প্রক্সির টার্গেট এন্ডপয়েন্টে কোনো টিএলএস-সক্ষম ব্যাকএন্ড সার্ভারে এইচটিটিপি রিকোয়েস্ট ভুলভাবে কনফিগার করা থাকলে এই ত্রুটিটি ঘটে।

রোগ নির্ণয়

ট্রেস টুল ব্যবহার করে ত্রুটি নির্ণয় করতে নিম্নলিখিত ধাপগুলো অনুসরণ করুন:

প্রভাবিত এপিআই প্রক্সির জন্য Apigee UI-তে ট্রেস (Trace) সক্রিয় করুন।
এপিআই প্রক্সিতে অনুরোধ পাঠান।
যেসব এপিআই অনুরোধ 400 প্রতিক্রিয়া কোডের কারণে ব্যর্থ হয়েছে, সেগুলোর মধ্যে একটি নির্বাচন করুন।
বিভিন্ন পর্যায়গুলো পর্যালোচনা করুন এবং ব্যর্থতাটি কোথায় ঘটেছে তা নির্ধারণ করুন।
সাধারণত আপনি ব্যাকএন্ড সার্ভার থেকে 400 এরর রেসপন্স আসতে দেখবেন। অর্থাৎ, আপনি নীচে দেখানো 'টার্গেট সার্ভার থেকে প্রাপ্ত রেসপন্স' পর্যায়ে 400 এরর রেসপন্সটি দেখতে পাবেন:
ট্রেস-এ থাকা AX (অ্যানালিটিক্স ডেটা রেকর্ডেড) আইকনে ক্লিক করে সেই টার্গেট এন্ডপয়েন্টটি নির্ধারণ করুন যার জন্য অনুরোধটি করা হয়েছিল।
target.url- টি লক্ষ্য করুন, যাতে প্রোটোকল, ব্যাকএন্ড সার্ভার হোস্ট অ্যালিয়াস এবং কখনও কখনও পোর্ট নম্বর থাকে। টার্গেট ইউআরএল-এর জন্য ব্যবহৃত পোর্টটি হলো 443 , কিন্তু প্রোটোকলটি হলো HTTP।
কনফিগারেশনটি বোঝার জন্য টার্গেট এন্ডপয়েন্টের সংজ্ঞাটি পর্যালোচনা করুন।
যাচাই করুন যে ব্যাকএন্ড সার্ভার হোস্টটি সুরক্ষিত এবং 443 মতো একটি সুরক্ষিত পোর্টে লিসেন করছে। যদি আপনি <URL> এলিমেন্টে প্রোটোকল হিসেবে http ব্যবহার করে থাকেন, তাহলে সেটাই এই সমস্যার কারণ।
নমুনা টার্গেট এন্ডপয়েন্ট কনফিগারেশন:
```
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<TargetEndpoint name="default">
    <Description/>
    <FaultRules/>
    <PreFlow name="PreFlow">
        <Request/>
        <Response/>
    </PreFlow>
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <Flows/>
    <HTTPTargetConnection>
        <Properties/>
        <URL>http://somehost.org:443/get</URL>
    </HTTPTargetConnection>
</TargetEndpoint>
```
উপরের উদাহরণটি দেখাচ্ছে যে আপনি HTTP প্রোটোকল ব্যবহার করছেন, কিন্তু ব্যবহৃত পোর্টটি হলো সুরক্ষিত পোর্ট 443 এর ফলে ব্যাকএন্ড সার্ভার 400 Bad Request এবং The plain HTTP request was sent to HTTPS port এই ত্রুটি বার্তাটি দিয়ে সাড়া দেয়।

সমাধান

যদি আপনার ব্যাকএন্ড সার্ভারটি সুরক্ষিত/TLS-সক্ষম হয়, তাহলে নিশ্চিত করুন যে আপনি টার্গেট এন্ডপয়েন্টের <URL> এলিমেন্টে প্রোটোকল হিসেবে https ব্যবহার করছেন, যেমনটি নিম্নলিখিত উদাহরণে দেখানো হয়েছে:
নমুনা টার্গেট এন্ডপয়েন্ট কনফিগারেশন:
```
<HTTPTargetConnection>
    <Properties/>
    <URL>https://somehost.org:443/get</URL>
</HTTPTargetConnection>
```
দ্রষ্টব্য: স্ট্যান্ডার্ড সুরক্ষিত পোর্ট 443 এর সাথে HTTPS প্রোটোকল ব্যবহার করার সময় পোর্ট নম্বর উল্লেখ করার প্রয়োজন নেই। এই উদাহরণে বোঝার সুবিধার জন্য পোর্ট নম্বরটি ব্যবহার করা হয়েছে।
যদি আপনার ব্যাকএন্ড সার্ভারটি অসুরক্ষিত হয়, তাহলে:
- 443 এর মতো সুরক্ষিত পোর্ট নম্বর উল্লেখ করবেন না।
- আপনার ব্যাকএন্ড সার্ভার যদি একটি সাধারণ অসুরক্ষিত পোর্টে লিসেন করে, তাহলে পোর্ট নম্বর উল্লেখ করার কোনো প্রয়োজন নেই।
- আপনি যদি অন্য কোনো অসুরক্ষিত পোর্ট ব্যবহার করেন, তাহলে পোর্ট নম্বরটি উল্লেখ করুন, যেমন: 9080
নমুনা টার্গেট এন্ডপয়েন্ট কনফিগারেশন:
```
<HTTPTargetConnection>
    <Properties/>
    <URL>http://somehost.org/get</URL>
</HTTPTargetConnection>

or

<HTTPTargetConnection>
    <Properties/>
    <URL>http://somehost.org:9080/get</URL>
</HTTPTargetConnection>
```

কারণ: ভুল টার্গেট সার্ভার কনফিগারেশন

যদি টার্গেট সার্ভারটি SSL সক্রিয় না করে 443 মতো কোনো সুরক্ষিত পোর্টে কনফিগার করা থাকে, তাহলে Apigee Edge-এর মেসেজ প্রসেসর একটি সুরক্ষিত বা TLS-কনফিগার করা টার্গেট সার্ভারে HTTP অনুরোধ পাঠায়, যার ফলে এই সমস্যাটি দেখা দেয়।

রোগ নির্ণয়

ট্রেস টুল ব্যবহার করে ত্রুটি নির্ণয় করতে নিম্নলিখিত ধাপগুলো অনুসরণ করুন:

প্রভাবিত এপিআই প্রক্সির জন্য Apigee UI-তে ট্রেস (Trace) সক্রিয় করুন।
এপিআই প্রক্সিতে অনুরোধ পাঠান।
যেসব এপিআই অনুরোধ 400 প্রতিক্রিয়া কোডের কারণে ব্যর্থ হয়েছে, সেগুলোর মধ্যে একটি নির্বাচন করুন।
বিভিন্ন পর্যায়গুলো পর্যালোচনা করুন এবং ব্যর্থতাটি কোথায় ঘটেছে তা নির্ধারণ করুন।
সাধারণত আপনি ব্যাকএন্ড সার্ভার থেকে 400 এরর রেসপন্স আসতে দেখবেন। অর্থাৎ, আপনি নীচে দেখানো 'টার্গেট সার্ভার থেকে প্রাপ্ত রেসপন্স' পর্যায়ে 400 এরর রেসপন্সটি দেখতে পাবেন:
ট্রেস-এ থাকা AX (অ্যানালিটিক্স ডেটা রেকর্ডেড) আইকনে ক্লিক করে সেই টার্গেট এন্ডপয়েন্টটি নির্ধারণ করুন যার জন্য অনুরোধটি করা হয়েছিল।
target.name লক্ষ্য করুন, যা টার্গেট এন্ডপয়েন্টের নাম নির্দেশ করে।
উপরের উদাহরণ ট্রেস ফাইলটিতে, target.name- এর মান default । এটি নির্দেশ করে যে এই অনুরোধের জন্য ব্যবহৃত টার্গেট এন্ডপয়েন্টটি হলো ডিফল্ট।
কনফিগারেশনটি বোঝার জন্য টার্গেট এন্ডপয়েন্টের সংজ্ঞাটি পর্যালোচনা করুন।
নমুনা টার্গেট এন্ডপয়েন্ট কনফিগারেশন:
```
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<TargetEndpoint name="default">
    <Description/>
    <FaultRules/>
    <PreFlow name="PreFlow">
        <Request/>
        <Response/>
    </PreFlow>
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <Flows/>
    <HTTPTargetConnection>
        <Properties/>
        <LoadBalancer>
        <Server name="faulty-target"/>
        </LoadBalancer>
    </HTTPTargetConnection>
</TargetEndpoint>
```
উপরের নমুনা টার্গেট এন্ডপয়েন্ট কনফিগারেশন থেকে দেখা যাচ্ছে যে, আপনি faulty-target নামের একটি টার্গেট সার্ভার ব্যবহার করছেন।
একবার আপনার কাছে টার্গেট সার্ভারের নাম চলে এলে, আপনি নিম্নলিখিত পদ্ধতিগুলোর মধ্যে যেকোনো একটি ব্যবহার করে টার্গেট সার্ভারের কনফিগারেশন পরীক্ষা করতে পারেন:
- এজ ইউআই
- ম্যানেজমেন্ট এপিআই

এজ ইউআই

Apigee Edge > Admin > Environments > Target Servers- এ যান।
এপিআই প্রক্সি থেকে শনাক্ত করা নির্দিষ্ট টার্গেট সার্ভারটি বেছে নিন এবং -এ ক্লিক করুন।
টার্গেট সার্ভারের জন্য নির্দিষ্ট পোর্ট এবং SSL তথ্য যাচাই করুন।
যদি টার্গেট সার্ভারটি একটি সুরক্ষিত পোর্ট (যেমন: 443 ) দিয়ে কনফিগার করা থাকে, কিন্তু SSL সক্রিয় করা না থাকে, তাহলে সেটাই এই সমস্যার কারণ।
উপরের স্ক্রিনশটে যেমন দেখতে পাচ্ছেন, ব্যবহৃত পোর্টটি হলো 443 , কিন্তু টার্গেট সার্ভার কনফিগারেশনে সেই পোর্টের জন্য SSL সক্রিয় করা নেই। এর ফলে Apigee Edge-এর মেসেজ প্রসেসর সুরক্ষিত পোর্ট 443 -এ HTTP রিকোয়েস্ট পাঠায়। তাই, আপনি The plain HTTP request was sent to HTTPS port মেসেজ সহ 400 Bad Request এররটি পান।

ম্যানেজমেন্ট এপিআই

নির্দিষ্ট টার্গেট সার্ভারের কনফিগারেশন সম্পর্কে বিস্তারিত জানতে, নিচে দেখানো অনুযায়ী Get target server API-টি চালান:
পাবলিক ক্লাউড ব্যবহারকারী:
```
curl -v 'https://api.enterprise.apigee.com/v1/organizations/ORG_NAME/environments/ENV_NAME>/targetservers/TARGET_SERVER_NAME' \
-H "Content-Type:application/xml" \
-H "Authorization:Bearer $TOKEN"
```
প্রাইভেট ক্লাউড ব্যবহারকারী:
```
curl -v 'http://MANAGEMENT_IP:8080/v1/organizations/ORG_NAME/environments/ENV_NAME/targetservers/TARGET_SERVER_NAME' \
-H "Content-Type:application/xml" \
-H "Authorization:Bearer $TOKEN"
```
টার্গেট সার্ভারের জন্য নির্দিষ্ট পোর্ট এবং SSL তথ্য যাচাই করুন।
যদি টার্গেট সার্ভারটি একটি সুরক্ষিত পোর্ট (যেমন: 443 ) দিয়ে কনফিগার করা থাকে, কিন্তু SSLInfo সেকশনটি সংজ্ঞায়িত বা সক্রিয় করা না থাকে, তাহলে সেটাই এই সমস্যার কারণ।
নমুনা টার্গেট সার্ভার কনফিগারেশন:
```
{
  "host" : "somehost.org",
  "isEnabled" : true,
  "name" : "faulty-target",
  "port" : 443
}
```
উপরের নমুনা আউটপুটে আমরা দেখতে পাচ্ছি যে, টার্গেট কানেকশনের জন্য ব্যবহৃত পোর্টটি হলো 443 , কিন্তু SSLInfo কনফিগ ব্লক নেই।
এর ফলে Apigee Edge-এর মেসেজ প্রসেসর সুরক্ষিত পোর্ট 443 এ HTTP অনুরোধ পাঠায়। তাই, আপনি The plain HTTP request was sent to HTTPS port বার্তা সহ 400 Bad Request ত্রুটিটি পান।

সমাধান

যদি আপনার টার্গেট সার্ভারটি সুরক্ষিত বা TLS-কনফিগার করা থাকে, তাহলে আপনাকে নির্দিষ্ট টার্গেট সার্ভারটির জন্য SSL সক্রিয় করতে হবে।

আপনি নিম্নলিখিত বিকল্পগুলির মধ্যে যেকোনো একটি ব্যবহার করে এটি করতে পারেন:

এজ ইউআই
ম্যানেজমেন্ট এপিআই

এজ ইউআই

Edge UI > Admin > Environments > Target Servers- এ গিয়ে টার্গেট সার্ভারটিতে যান।
নির্দিষ্ট টার্গেট সার্ভারটি বেছে নিন এবং -এ ক্লিক করুন।
যদি আপনার টার্গেট সার্ভারটি সুরক্ষিত হয় এবং 443 মতো কোনো পোর্ট ব্যবহার করে, তাহলে SSL অপশনের পাশের চেকবক্সটি সিলেক্ট করে SSL সক্রিয় করুন।
ট্রাস্টস্টোর , সাইফার এবং প্রোটোকল কনফিগার করুন। (শুধুমাত্র প্রয়োজন হলে)

ম্যানেজমেন্ট এপিআই

"টার্গেট সার্ভার কনফিগারেশন আপডেট করুন" ডকুমেন্টেশনে বর্ণিত পদ্ধতি অনুযায়ী ম্যানেজমেন্ট এপিআই ব্যবহার করে টার্গেট সার্ভারটি কনফিগার করুন।

রোগ নির্ণয়ের তথ্য অবশ্যই সংগ্রহ করতে হবে

উপরোক্ত নির্দেশাবলী অনুসরণ করার পরেও যদি সমস্যাটি থেকে যায়, তাহলে নিম্নলিখিত ডায়াগনস্টিক তথ্য সংগ্রহ করুন এবং তারপর Apigee Edge Support-এর সাথে যোগাযোগ করুন।

আপনি যদি পাবলিক ক্লাউড ব্যবহারকারী হন, তাহলে নিম্নলিখিত তথ্য প্রদান করুন:
- সংস্থার নাম
- পরিবেশের নাম
- এপিআই প্রক্সি নাম
- ত্রুটিটি পুনরুৎপাদন করতে সম্পূর্ণ কার্ল (curl) কমান্ডটি ব্যবহার করুন।
- ট্রেস টুলের আউটপুট (যদি আপনি ব্যর্থ অনুরোধটি ক্যাপচার করতে সক্ষম হয়ে থাকেন)
আপনি যদি প্রাইভেট ক্লাউড ব্যবহারকারী হন, তাহলে নিম্নলিখিত তথ্য প্রদান করুন:
- সম্পূর্ণ ত্রুটি বার্তা পরিলক্ষিত হয়েছে
- পরিবেশের নাম
- এপিআই প্রক্সি বান্ডেল
- টার্গেট সার্ভারের সংজ্ঞা (যদি আপনি আপনার এন্ডপয়েন্টে টার্গেট সার্ভার ব্যবহার করে থাকেন)
- ট্রেস টুলের আউটপুট (যদি আপনি ব্যর্থ অনুরোধটি ক্যাপচার করতে সক্ষম হয়ে থাকেন)