414 অনুরোধ-ইউআরআই খুব দীর্ঘ - খুব বড় লাইন

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

লক্ষণ

ক্লায়েন্ট অ্যাপ্লিকেশনটি এপিআই কলের প্রতিক্রিয়া হিসেবে 414 Request-URI Too Long এইচটিটিপি স্ট্যাটাস কোড এবং protocol.http.TooBigLine এরর কোড পায়।

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

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

HTTP/1.1 414 Request-URI Too Long

এছাড়াও, আপনি নিম্নলিখিত ত্রুটি বার্তাটি দেখতে পারেন:

{
   "fault":{
      "faultstring":"request line size exceeding 7,168",
      "detail":{
         "errorcode":"protocol.http.TooBigLine"
      }
   }
}

উল্লেখ্য যে, উপরের ত্রুটি বার্তার faultstring টিতে Apigee Edge-এ রিকোয়েস্ট লাইনের জন্য অনুমোদিত সীমা উল্লেখ করা আছে, যা হলো 7168 bytes (৭ কিলোবাইট)।

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

ক্লায়েন্ট অ্যাপ্লিকেশন থেকে HTTP অনুরোধের অংশ হিসেবে Apigee Edge-এ পাঠানো রিকোয়েস্ট লাইনের আকার Apigee Edge-এ অনুমোদিত সীমার চেয়ে বেশি হলে এই ত্রুটিটি ঘটে।

এই ত্রুটির সম্ভাব্য কারণগুলো দেখার আগে, চলুন জেনে নেওয়া যাক রিকোয়েস্ট লাইন বলতে কী বোঝায় এবং এর সাইজ কীভাবে পরীক্ষা করতে হয়।

অনুরোধ-লাইন বোঝা

একটি সাধারণ HTTP অনুরোধ তিনটি অংশ নিয়ে গঠিত:

1. অনুরোধ-লাইন
2. HTTP হেডারসমূহের সেট
3. [ দেহ ]

অনুরোধ লাইনটি নিচে দেখানো অনুযায়ী তিনটি অংশ নিয়ে গঠিত।

Request-Line = <Method> <Request-URI> <HTTP-Version>

যখন ক্লায়েন্ট অ্যাপ্লিকেশন থেকে সার্ভারে একটি HTTP অনুরোধ পাঠানো হয়, তখন সার্ভারে পাঠানো প্রথম লাইনে উপরে বর্ণিত Request-Line-টি থাকে। এর পরে হেডার এবং রিকোয়েস্ট বডি/পে-লোড থাকে।

নিম্নলিখিত নমুনা স্ক্রিনশটটিতে একটি সাধারণ curl রিকোয়েস্ট, এর রিকোয়েস্ট অংশ (রিকোয়েস্ট-লাইন সহ) এবং রেসপন্স অংশ দেখানো হয়েছে।

অনুরোধ-লাইনের আকার বোঝা

1. উপরে আলোচিত নমুনাটিতে, অনুরোধের শুরুর লাইন (প্রথম লাইন), যা রিকোয়েস্ট-লাইন নামেও পরিচিত, তা নিম্নরূপ:

   GET /test/ HTTP/1.1

   রিকোয়েস্ট-লাইনের সাইজ ~19 bytes কারণ এতে 19 ASCII characters রয়েছে। যেহেতু এটি Apigee Edge-এর অনুমোদিত সীমার মধ্যে, তাই অনুরোধটি কোনো ত্রুটি ছাড়াই প্রসেস করা হয় এবং আপনি একটি সফল রেসপন্স পান।

2. একইভাবে, আপনি যদি উপরে দেখানো ত্রুটির বার্তার faultstring দেখেন, তাহলে দেখবেন তাতে "request line size exceeding 7,168" লেখা আছে। এটি নির্দেশ করে যে ক্লায়েন্টের করা HTTP অনুরোধের রিকোয়েস্ট-লাইন (Request-Line) ৭,১৬৮ বাইট অতিক্রম করেছে।

এই ত্রুটির সম্ভাব্য কারণগুলো নিচে দেওয়া হলো:

সাধারণ রোগ নির্ণয়ের পদক্ষেপ

এই ত্রুটি নির্ণয় করতে নিম্নলিখিত সরঞ্জাম/কৌশলগুলোর মধ্যে যেকোনো একটি ব্যবহার করুন:

কারণ: অনুরোধ পেলোডের আকার অনুমোদিত সীমার চেয়ে বড়।

রোগ নির্ণয়

1. সাধারণ রোগ নির্ণয়ের ধাপগুলিতে ব্যাখ্যা করা অনুযায়ী API মনিটরিং, ট্রেস টুল বা NGINX অ্যাক্সেস লগ ব্যবহার করে পরিলক্ষিত ত্রুটির জন্য ফল্ট কোড , ফল্ট সোর্স এবং রিকোয়েস্ট-লেংথ সাইজ নির্ধারণ করুন।
2. যদি ফল্ট সোর্সের মান apigee বা MP হয়, তাহলে এটি নির্দেশ করে যে ক্লায়েন্ট অ্যাপ্লিকেশন দ্বারা Apigee-তে পাঠানো অনুরোধের আকার Apigee Edge-এ অনুমোদিত সীমার চেয়ে বেশি।
3. নিম্নলিখিত পদ্ধতিগুলোর যেকোনো একটি ব্যবহার করে আপনি যাচাই করতে পারেন যে রিকোয়েস্ট লাইনের সাইজ অনুমোদিত ৭ কেবি সীমা অতিক্রম করেছে কিনা:

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

   ত্রুটির বার্তা ব্যবহার করে যাচাই করতে:

   আপনার কাছে যদি Apigee Edge থেকে প্রাপ্ত সম্পূর্ণ এরর মেসেজটি থাকে, তাহলে faultstring টি দেখুন। faultstring টি নির্দেশ করে যে Request-Line-এর সাইজ ৭ কিলোবাইটের অনুমোদিত সীমা অতিক্রম করেছে।

   নমুনা ত্রুটি বার্তা:

   "faultstring":"request line size exceeding 7,168"

   প্রকৃত অনুরোধ

   প্রকৃত অনুরোধ ব্যবহার করে যাচাই করতে:

   ক্লায়েন্ট অ্যাপ্লিকেশন দ্বারা করা প্রকৃত অনুরোধটি যদি আপনার কাছে থাকে, তাহলে নিম্নলিখিত পদক্ষেপগুলি অনুসরণ করুন:

   1. অনুরোধে পাঠানো URI-টির আকার যাচাই করুন।

   2. Apigee Edge-এ যদি আপনি দেখেন যে URI-এর আকার অনুমোদিত সীমার চেয়ে বেশি, তাহলে সেটাই সমস্যার কারণ।

      নমুনা অনুরোধ:

      curl http://<hostalias>/testtoobigline?_qparam=000000000000000000……..000000<trimmed> -k -X POST
      

      উপরোক্ত ক্ষেত্রে, কোয়েরি প্যারামিটার qparam এর মান ৭ কেবি-র চেয়ে বড়, অর্থাৎ এতে ৭ হাজারের বেশি ASCII অক্ষর রয়েছে।

      আপনি যদি অন্য কোনো ক্লায়েন্ট ব্যবহার করেন, তাহলে ক্লায়েন্ট লগগুলো পর্যালোচনা করে Apigee Edge-এ পাঠানো রিকোয়েস্ট লাইনের সাইজ খুঁজে বের করার চেষ্টা করতে পারেন।

   মেসেজ প্রসেসর লগ

   মেসেজ প্রসেসর লগ ব্যবহার করে যাচাই করতে:

   আপনি যদি একজন প্রাইভেট ক্লাউড ব্যবহারকারী হন, তাহলে Apigee Edge-এ Request-Line-এর আকার অনুমোদিত সীমা অতিক্রম করেছে কিনা তা যাচাই করতে Message Processor লগ ব্যবহার করতে পারেন।

   1. মেসেজ প্রসেসর লগগুলো পরীক্ষা করুন:

      /opt/apigee/var/log/edge-message-processor/logs/system.log

   2. একটি নির্দিষ্ট সময়কালে কোনো 414 ত্রুটি ছিল কিনা (যদি সমস্যাটি অতীতে ঘটে থাকে) অথবা এখনও কোনো অনুরোধ 414 কারণে ব্যর্থ হচ্ছে কিনা তা অনুসন্ধান করুন। আপনি নিম্নলিখিত সার্চ স্ট্রিংগুলি ব্যবহার করতে পারেন।

      grep -ri "exceeding"
      

      grep -ri "RequestURITooLong"
      

   3. আপনি system.log এ নিম্নলিখিতগুলির মতো লাইন খুঁজে পাবেন:

      2021-07-12 08:53:31,461  NIOThread@0 ERROR ADAPTORS.HTTP.FLOW -
      AbstractRequestListener.onException() : Request:null, uri:null,
      message Id:null, exception:com.apigee.errors.http.user.RequestURITooLong{
      code = protocol.http.TooBigLine, message = request line size exceeding 7,168,
      associated contexts = []}, context:Context@366f4217
      input=ClientInputChannel(SSLClientChannel[Accepted: Remote:192.168.195.90:8443
      Local:192.168.67.23:34256]@301912 useCount=1 bytesRead=0 bytesWritten=45849
      age=2254670ms lastIO=0ms isOpen=true)

      উপরের এরর মেসেজে থাকা message = request line size exceeding 7,168 নির্দেশ করে যে রিকোয়েস্ট ইউআরআই (Request URI)-এর সাইজ ৭ কেবি (KB)-এর বেশি। তাই, Apigee Edge ক্লায়েন্ট অ্যাপ্লিকেশনগুলোতে com.apigee.errors.http.user.RequestURITooLong এক্সেপশনটি থ্রো করে এবং protocol.http.TooBigline ফল্ট কোডসহ 414 স্ট্যাটাস কোড রিটার্ন করে।

সমাধান

সীমা

Apigee আশা করে যে ক্লায়েন্ট অ্যাপ্লিকেশন এবং ব্যাকএন্ড সার্ভার এমন কোনো Request/Response-Line পাঠাবে না, যার আকার Apigee Edge Limits- এ নথিভুক্ত Request/Response Line Limit-এর জন্য নির্ধারিত অনুমোদিত সীমার চেয়ে বড়।

1. আপনি যদি একজন পাবলিক ক্লাউড ব্যবহারকারী হন, তাহলে রিকোয়েস্ট এবং রেসপন্স লাইনের আকারের সর্বোচ্চ সীমা Apigee Edge Limits- এ উল্লেখিত নিয়ম অনুযায়ী হবে।
2. আপনি যদি একজন প্রাইভেট ক্লাউড ব্যবহারকারী হন, তাহলে আপনি হয়তো রিকোয়েস্ট এবং রেসপন্স-লাইন সাইজের ডিফল্ট সর্বোচ্চ সীমা পরিবর্তন করে থাকতে পারেন (যদিও এটি একটি অনুচিত কাজ)। ‘বর্তমান সীমা কীভাবে পরীক্ষা করবেন’ অংশে দেওয়া নির্দেশাবলী অনুসরণ করে আপনি সর্বোচ্চ রিকোয়েস্ট-লাইন সাইজের সীমা নির্ধারণ করতে পারেন।

বর্তমান সীমা কীভাবে পরীক্ষা করবেন?

এই অংশে ব্যাখ্যা করা হয়েছে কিভাবে যাচাই করতে হয় যে মেসেজ প্রসেসরগুলিতে HTTPRequest.line.limit প্রপার্টিটি একটি নতুন মান দ্বারা আপডেট করা হয়েছে।

1. মেসেজ প্রসেসর মেশিনে, /opt/apigee/edge-message-processor/conf ডিরেক্টরিতে HTTPRequest.line.limit প্রপার্টিটি খুঁজুন এবং নিচে দেখানো অনুযায়ী কী মান সেট করা হয়েছে তা পরীক্ষা করে দেখুন:

   grep -ri "HTTPRequest.line.limit" /opt/apigee/edge-message-processor/conf
   

2. উপরোক্ত কমান্ড থেকে প্রাপ্ত নমুনা ফলাফলটি নিম্নরূপ:

   /opt/apigee/edge-message-processor/conf/http.properties:HTTPRequest.line.limit=7k

3. উপরের উদাহরণ আউটপুটে লক্ষ্য করুন যে, http.properties ফাইলে HTTPRequest.line.limit প্রপার্টিটির মান 7k সেট করা হয়েছে।

   এর থেকে বোঝা যায় যে, Apigee for Private Cloud-এ কনফিগার করা Request-Line সাইজের সীমা হলো ৭ কিলোবাইট।

আপনার যদি এখনও Apigee Support-এর কাছ থেকে কোনো সাহায্যের প্রয়োজন হয়, তাহলে Must gather diagnostic information- এ যান।

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

নিম্নলিখিত ডায়াগনস্টিক তথ্য সংগ্রহ করুন, এবং তারপর Apigee Edge Support-এর সাথে যোগাযোগ করুন:

আপনি যদি পাবলিক ক্লাউড ব্যবহারকারী হন, তাহলে নিম্নলিখিত তথ্যগুলো প্রদান করুন:

• সংস্থার নাম
• পরিবেশের নাম
• এপিআই প্রক্সি নাম
• 414 ত্রুটিটি পুনরুৎপাদন করতে ব্যবহৃত সম্পূর্ণ curl কমান্ড।
• এপিআই অনুরোধগুলির ট্রেস ফাইল

আপনি যদি একজন প্রাইভেট ক্লাউড ব্যবহারকারী হন, তাহলে নিম্নলিখিত তথ্যগুলো প্রদান করুন:

• ব্যর্থ অনুরোধগুলির জন্য সম্পূর্ণ ত্রুটি বার্তা পরিলক্ষিত হয়েছে।
• সংস্থার নাম
• পরিবেশের নাম
• এপিআই প্রক্সি বান্ডেল
• ব্যর্থ হওয়া এপিআই অনুরোধগুলির ট্রেস ফাইল
• 414 ত্রুটিটি পুনরুৎপাদন করতে ব্যবহৃত সম্পূর্ণ curl কমান্ড।

• NGINX অ্যাক্সেস লগ /opt/apigee/var/log/edge-router/nginx/ ORG ~ ENV . PORT# _access_log

  যেখানে: ORG , ENV এবং PORT# প্রকৃত মান দ্বারা প্রতিস্থাপিত হয়।

• মেসেজ প্রসেসর সিস্টেম লগ /opt/apigee/var/log/edge-message-processor/logs/system.log