414 अनुरोध-यूआरआई बहुत लंबा है - TOBigLine

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

समस्या का ब्यौरा

क्लाइंट ऐप्लिकेशन को एपीआई कॉल के रिस्पॉन्स के तौर पर, गड़बड़ी कोड protocol.http.TooBigLine के साथ 414 Request-URI Too Long का एचटीटीपी स्टेटस कोड मिलता है.

गड़बड़ी का मैसेज

क्लाइंट ऐप्लिकेशन को यह रिस्पॉन्स कोड मिलता है:

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 (7 केबी) है.

संभावित कारण

यह गड़बड़ी तब होती है, जब एचटीटीपी अनुरोध के तौर पर क्लाइंट ऐप्लिकेशन से Apigee Edge को भेजी गई अनुरोध लाइन का साइज़, Apigee Edge में दी गई अनुमति वाली सीमा से ज़्यादा हो.

इस गड़बड़ी की संभावित वजहों को देखने से पहले, आइए जानें कि अनुरोध वाली लाइन का क्या मतलब है और इसके साइज़ की जांच कैसे की जाती है.

अनुरोध-लाइन को समझना

एक सामान्य एचटीटीपी अनुरोध के तीन हिस्से होते हैं:

1. अनुरोध-लाइन
2. ( HTTP हेडर का सेट )
3. [ मुख्य भाग ]

अनुरोध पंक्ति के तीन हिस्से होते हैं, जैसा कि नीचे दिखाया गया है.

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

जब क्लाइंट ऐप्लिकेशन किसी सर्वर को एचटीटीपी अनुरोध करता है, तो सर्वर पर जाने वाली पहली लाइन में ऊपर बताई गई अनुरोध-लाइन शामिल होती है. इसके बाद, हेडर और अनुरोध का मुख्य हिस्सा/पेलोड का अनुरोध करें.

नीचे दिए गए सैंपल में, curl का सामान्य अनुरोध, अनुरोध का हिस्सा (अनुरोध-लाइन के साथ) और रिस्पॉन्स वाला हिस्सा दिखाया गया है.

अनुरोध-लाइन के आकार को समझना

1. ऊपर जिस नमूने के बारे में बताया गया है, उसकी शुरुआती लाइन (पहली लाइन) को अनुरोध-लाइन भी कहा जाता है. यह लाइन यहां दी गई है:

   GET /test/ HTTP/1.1
   

   अनुरोध-लाइन का साइज़ ~19 bytes है, क्योंकि इसमें 19 ASCII characters शामिल है. यह Apigee Edge में दी गई अनुमति के अंदर है, इसलिए अनुरोध को बिना किसी गड़बड़ी के प्रोसेस किया जाता है और आपको सही जवाब मिलता है.

2. इसी तरह, अगर ऊपर दिखाए गए गड़बड़ी के मैसेज में faultstring देखें, तो उसमें "request line size exceeding 7,168" है. इससे पता चलता है कि क्लाइंट के एचटीटीपी अनुरोध की अनुरोध लाइन 7,168 बाइट से ज़्यादा है.

इस गड़बड़ी की ये वजहें हो सकती हैं:

वजह	ब्यौरा	समस्या हल करने के लिए निर्देश
अनुरोध पेलोड का साइज़, तय सीमा से ज़्यादा है	क्लाइंट ऐप्लिकेशन से Apigee Edge को भेजे गए अनुरोध-यूआरआई का साइज़, Apigee Edge में मंज़ूर की गई सीमा से ज़्यादा है.	Edge के सार्वजनिक और निजी क्लाउड के उपयोगकर्ता

निदान के सामान्य चरण

इस गड़बड़ी का पता लगाने के लिए, नीचे दिए गए किसी टूल/तकनीक का इस्तेमाल करें:

वजह: अनुरोध वाले पेलोड का साइज़, तय सीमा से ज़्यादा है

संक्रमण की जांच

1. एपीआई मॉनिटरिंग, ट्रेस टूल या NGINX ऐक्सेस लॉग का इस्तेमाल करके मिली गड़बड़ी के लिए, गलत कोड, गड़बड़ी का सोर्स, और अनुरोध की अवधि का साइज़ तय करें. डाइग्नोस्टिक के सामान्य तरीके में बताया गया तरीका.
2. अगर गलत सोर्स की वैल्यू apigee या MP है, तो इससे पता चलता है कि क्लाइंट ऐप्लिकेशन से Apigee को भेजे गए अनुरोध का साइज़, Apigee Edge में बताई गई सीमा से ज़्यादा है.
3. नीचे दिए गए तरीकों में से किसी एक का इस्तेमाल करके पुष्टि की जा सकती है कि अनुरोध के लिए लाइन का साइज़, सात केबी की तय सीमा से ज़्यादा है या नहीं:

   गड़बड़ी का मैसेज

   गड़बड़ी के मैसेज का इस्तेमाल करके पुष्टि करने के लिए:

   अगर आपके पास Apigee Edge से मिले गड़बड़ी के पूरे मैसेज का ऐक्सेस है, तो faultstring देखें. faultstring से पता चलता है कि अनुरोध लाइन का साइज़ 7 केबी की तय सीमा से ज़्यादा है.

   गड़बड़ी के मैसेज का सैंपल:

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

   वास्तविक अनुरोध

   वास्तविक अनुरोध का इस्तेमाल करके पुष्टि करने के लिए:

   अगर आपके पास क्लाइंट ऐप्लिकेशन के किए गए असल अनुरोध का ऐक्सेस है, तो यह तरीका अपनाएं:

   1. अनुरोध में पास किए गए यूआरआई के साइज़ की पुष्टि करें.

   2. अगर आपको लगता है कि यूआरआई का साइज़, Apigee Edge में दी गई अनुमति की सीमा से ज़्यादा है, तो ही समस्या की वजह है.

      अनुरोध का उदाहरण:

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

      ऊपर दिए गए मामले में, क्वेरी पैरामीटर qparam की वैल्यू 7 केबी से ज़्यादा है. इसका मतलब है कि इसमें 7 K से ज़्यादा ASCII वर्ण हैं.

      अगर किसी दूसरे क्लाइंट का इस्तेमाल किया जा रहा है, तो क्लाइंट लॉग की समीक्षा करके, Apigee Edge को भेजी जा रही अनुरोध लाइन का साइज़ पता करने की कोशिश की जा सकती है.

   मैसेज प्रोसेसर के लॉग

   Message प्रोसेसर लॉग का इस्तेमाल करके पुष्टि करने के लिए:

   अगर आप Private Cloud के उपयोगकर्ता हैं, तो Message प्रोसेसर लॉग का इस्तेमाल करके यह पुष्टि की जा सकती है कि अनुरोध लाइन का साइज़, Apigee Edge में स्वीकार की गई सीमा से ज़्यादा है या नहीं.

   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 टेक्स्ट बताता है कि अनुरोध के यूआरआई का साइज़ 7 केबी से ज़्यादा है. इसलिए, Apigee Edge, com.apigee.errors.http.user.RequestURITooLong अपवाद को फेंकता है और क्लाइंट ऐप्लिकेशन में 414 गड़बड़ी कोड protocol.http.TooBigline वाला स्टेटस कोड दिखाता है.

रिज़ॉल्यूशन

सीमाएं

Apigee को उम्मीद है कि क्लाइंट ऐप्लिकेशन और बैकएंड सर्वर, अनुरोध/रिस्पॉन्स-लाइन को नहीं भेजेगा. इनका साइज़, Apigee Edge की सीमा में, अनुरोध/रिस्पॉन्स लाइन की सीमा के मुताबिक तय की गई सीमा से ज़्यादा है.

1. अगर आप पब्लिक क्लाउड का इस्तेमाल करते हैं, तो अनुरोध और रिस्पॉन्स लाइन के साइज़ की तय सीमा, Apigee Edge की सीमा में अनुरोध/रिस्पॉन्स-लाइन साइज़ के लिए तय की गई है.
2. अगर आप प्राइवेट क्लाउड उपयोगकर्ता हैं, तो हो सकता है कि आपने अनुरोध और जवाब देने की लाइन के साइज़ की डिफ़ॉल्ट ज़्यादा से ज़्यादा सीमा में बदलाव किया हो. भले ही, यह सुझाया गया तरीका न हो. अनुरोध के लिए लाइन के साइज़ की ज़्यादा से ज़्यादा सीमा तय करने के लिए, मौजूदा सीमा कैसे देखें में दिए गए निर्देशों का पालन करें.

मौजूदा सीमा कैसे देखें?

इस सेक्शन में, इस बात की पुष्टि करने का तरीका बताया गया है कि मैसेज प्रोसेसर पर नई वैल्यू के साथ HTTPRequest.line.limit प्रॉपर्टी को अपडेट किया गया है या नहीं.

1. Message प्रोसेसर मशीन पर, /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. ऊपर दिए गए आउटपुट आउटपुट में, ध्यान दें कि HTTPRequest.line.limit प्रॉपर्टी को http.properties में, 7k वैल्यू के साथ सेट किया गया है.

   इससे पता चलता है कि Apigee for Private Cloud में, अनुरोध लाइन के साइज़ की सीमा 7 केबी है.

अगर आपको अब भी Apigee की सहायता टीम से मदद चाहिए, तो गड़बड़ी की जानकारी इकट्ठा करना ज़रूरी है पर जाएं.

ऐप्लिकेशन की परफ़ॉर्मेंस से जुड़ी जानकारी इकट्ठा करनी होगी

ऐप्लिकेशन की परफ़ॉर्मेंस से जुड़ी यह जानकारी इकट्ठा करें और Apigee Edge की सहायता टीम से संपर्क करें:

अगर आप Public Cloud उपयोगकर्ता हैं, तो यह जानकारी दें:

• संगठन का नाम
• परिवेश का नाम
• एपीआई प्रॉक्सी का नाम
• 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