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

यह Apigee Edge का दस्तावेज़ है.
Go to the Apigee X documentation. info

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

क्लाइंट ऐप्लिकेशन को एपीआई कॉल के जवाब में, गड़बड़ी कोड 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. ( एचटीटीपी हेडर का सेट )
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 बाइट से ज़्यादा है.

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

गड़बड़ी की जानकारी इकट्ठा करने के सामान्य चरण

इस गड़बड़ी की जानकारी इकट्ठा करने के लिए, इनमें से कोई टूल/तकनीक इस्तेमाल करें:

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

गड़बड़ी की जानकारी इकट्ठा करना

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

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

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

   अगर आपके पास 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 के से ज़्यादा एएससीआईआई वर्ण शामिल हैं.

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

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

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

   अगर Private Cloud के उपयोगकर्ता हैं, तो मैसेज प्रोसेसर के लॉग का इस्तेमाल करके, यह पुष्टि की जा सकती है कि अनुरोध लाइन का साइज़, 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 दिखाता है. साथ ही, क्लाइंट ऐप्लिकेशन को गड़बड़ी कोड protocol.http.TooBigline के साथ 414 स्टेटस कोड दिखाता है.

रिज़ॉल्यूशन

सीमाएं

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

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

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

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

1. मैसेज प्रोसेसर वाली मशीन पर, HTTPRequest.line.limit प्रॉपर्टी को /opt/apigee/edge-message-processor/conf डायरेक्ट्री में खोजें और देखें कि इसके लिए कौनसी वैल्यू सेट की गई है. इसके लिए, यहां दिया गया तरीका अपनाएं:

   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 वैल्यू सेट की गई है.

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

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

गड़बड़ी की जानकारी इकट्ठा करना

गड़बड़ी की यह जानकारी इकट्ठा करें. इसके बाद, Apigee Edge की सहायता टीम से संपर्क करें:

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

• संगठन का नाम
• परिवेश का नाम
• एपीआई प्रॉक्सी का नाम
• 414 गड़बड़ी को फिर से दिखाने के लिए इस्तेमाल किया गया पूरा curl निर्देश
• एपीआई अनुरोधों के लिए ट्रेस फ़ाइल

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

• पूरे न हो पाने वाले अनुरोधों के लिए, गड़बड़ी का पूरा मैसेज
• संगठन का नाम
• परिवेश का नाम
• एपीआई प्रॉक्सी बंडल
• पूरे न हो पाने वाले एपीआई अनुरोधों के लिए ट्रेस फ़ाइल
• 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