413 अनुरोध इकाई बहुत बड़ी है - ToBigBody

आपको Apigee Edge दस्तावेज़ दिख रहा है.
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है इस पेज पर जाएं Apigee X दस्तावेज़. जानकारी

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

क्लाइंट ऐप्लिकेशन को 413 Request Entity Too Large का एचटीटीपी स्टेटस कोड मिलता है एपीआई कॉल के रिस्पॉन्स के तौर पर, गड़बड़ी कोड protocol.http.TooBigBody का इस्तेमाल किया जा सकता है.

गड़बड़ी संदेश

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

HTTP/1.1 413 Request Entity Too Large

इसके अलावा, आपको गड़बड़ी का यह मैसेज भी दिख सकता है:

{
   "fault":{
      "faultstring":"Body buffer overflow",
      "detail":{
         "errorcode":"protocol.http.TooBigBody"
      }
   }
}

संभावित कारण

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

इस गड़बड़ी की संभावित वजहें यहां दी गई हैं :

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

गड़बड़ी की जांच करने के सामान्य तरीके

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

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

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

1. इसके लिए गलत कोड, गलत सोर्स, और पेलोड के साइज़ का अनुरोध करें एपीआई मॉनिटरिंग, ट्रेस टूल या NGINX ऐक्सेस लॉग का इस्तेमाल करने पर मिली गड़बड़ी, जैसा कि यहां बताया गया है स्थिति #1 (बिना कंप्रेस किए) के साथ गड़बड़ी की सामान्य जानकारी वाला तरीका.
2. अगर गलत सोर्स की वैल्यू policy या proxy है, तो इससे पता चलता है कि क्लाइंट ऐप्लिकेशन से Apigee को भेजे गए अनुरोध के पेलोड का साइज़ इससे ज़्यादा है Apigee Edge में स्वीकार की जाने वाली सीमा.
3. पहले चरण में तय किए गए पेलोड के साइज़ के अनुरोध की पुष्टि करें.
   • अगर पेलोड का साइज़ > 10 एमबी की सीमा तय नहीं होती है, तो गड़बड़ी की वजह भी यही होगी.
   • अगर पेलोड का साइज़ < ज़्यादा से ज़्यादा 10 एमबी हो सकते हैं. फिर भी, ऐसा हो सकता है कि अनुरोध पेलोड को कंप्रेस किए गए फ़ॉर्मैट में पास किया जाता है. पर जाएं वजह: डिकंप्रेशन के बाद, पेलोड का साइज़ तय सीमा से ज़्यादा हो गया है
4. यह भी पुष्टि की जा सकती है कि अनुरोध के पेलोड साइज़ का साइज़ वाकई में है या नहीं > 10 एमबी तक की अनुमति है नीचे दिए गए तरीके का इस्तेमाल करके असल अनुरोध की जांच करें:
   1. अगर आपके पास क्लाइंट ऐप्लिकेशन के किए गए असल अनुरोध का ऐक्सेस नहीं है, तो यहां जाएं रिज़ॉल्यूशन.
   2. अगर आपके पास क्लाइंट ऐप्लिकेशन के असल अनुरोध का ऐक्सेस है, तो इसके लिए, नीचे दिया गया तरीका अपनाएं:
      1. अनुरोध में पास किए गए पेलोड के साइज़ की पुष्टि करें.
      2. अगर आपको लगता है कि पेलोड का साइज़ सीमा तय करें, तो Apigee Edge की अनुमति है, तो यह समस्या की वजह है.

      अनुरोध का सैंपल:

      curl http://<hostalias>/testtoobigbody -k -X POST -F file=@test15mbfile -v
      

      ऊपर दिए गए मामले में, test15mbfile फ़ाइल का साइज़ ~15 एमबी है. अगर आपको किसी दूसरे क्लाइंट का इस्तेमाल कर रहे हैं, तो भेजे जा रहे पेलोड के साइज़ का पता लगाने के लिए क्लाइंट लॉग पाएं.

रिज़ॉल्यूशन

रिज़ॉल्यूशन पर जाएं.

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

अगर पेलोड को कंप्रेस किए गए फ़ॉर्मैट में भेजा गया है और अनुरोध हेडर है Content-Encoding को gzip, Apigee, अनुरोध को डिकंप्रेस करता है पेलोड. अगर Apigee को लगता है कि पेलोड का साइज़ ज़्यादा है, तो डीकंप्रेस की प्रोसेस के दौरान साइज़ 10 एमबी से ज़्यादा हो, सीमा हो जाती है, तो यह आगे होने वाले कंप्रेशन को बंद कर देती है और फिर से जवाब देती है गड़बड़ी कोड के साथ 413 Request Entity Too Large protocol.http.TooBigBody.

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

1. गड़बड़ी का कोड, गलत सोर्स, और पेलोड के साइज़ का अनुरोध करें को तय करें एपीआई मॉनिटरिंग, ट्रेस टूल या NGINX ऐक्सेस लॉग का इस्तेमाल करके मिली गड़बड़ी का पता लगाने के लिए स्थिति #2 (कंप्रेस्ड) के साथ, गड़बड़ी की सामान्य जानकारी पाने का तरीका.
2. अगर गलत सोर्स की वैल्यू policy या proxy है, तो इससे पता चलता है कि क्लाइंट ऐप्लिकेशन से Apigee को भेजे गए अनुरोध के पेलोड का साइज़ ज़्यादा है यह Apigee Edge में स्वीकार की जाने वाली सीमा से ज़्यादा है.
3. पहले चरण में बताए गए तरीके के मुताबिक, पेलोड के अनुरोध के साइज़ की पुष्टि करें.
   • अगर पेलोड का साइज़ > 10 एमबी की सीमा तय नहीं होती है, तो गड़बड़ी की वजह भी यही होगी.
   • अगर पेलोड का साइज़ < ज़्यादा से ज़्यादा 10 एमबी हो सकते हैं. फिर भी, ऐसा हो सकता है कि अनुरोध पेलोड को कंप्रेस किए गए फ़ॉर्मैट में पास किया जाता है. इस मामले में, कंप्रेस किए गए अनुरोध पेलोड.
4. आप यह पुष्टि कर सकते हैं कि क्लाइंट का अनुरोध कंप्रेस किए गए फ़ॉर्मैट में भेजा गया है या नहीं और इनमें से किसी एक का इस्तेमाल करके, कंप्रेस किया गया साइज़, तय सीमा से ज़्यादा था तरीका:

   ट्रेस

   ट्रेस करने वाले टूल की मदद से पुष्टि करने के लिए:

   1. अगर आपने पूरे न हो पाने वाले अनुरोध के लिए कोई ट्रेस कैप्चर कर ली है, तो यहां दिया गया तरीका अपनाएं Trace और
      1. client.received.content.length वैरिएबल की वैल्यू तय करें
      2. पुष्टि करें कि क्लाइंट के अनुरोध में, कॉन्टेंट को कोड में बदलने का तरीका शामिल है: gzip हेडर
   2. अगर client.received.content.length वैरिएबल की वैल्यू 10 एमबी, अनुमति है सीमा, और अनुरोध हेडर कॉन्टेंट-एन्कोडिंग: gzip, तो इस गड़बड़ी की वजह यही है.

   असल अनुरोध

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

   1. अगर आपके पास क्लाइंट ऐप्लिकेशन के किए गए असल अनुरोध का ऐक्सेस नहीं है, तो यहां जाएं रिज़ॉल्यूशन.
   2. अगर आपके पास क्लाइंट ऐप्लिकेशन के असल अनुरोध का ऐक्सेस है, तो इसके लिए, नीचे दिया गया तरीका अपनाएं:
      1. अनुरोध में पास किए गए पेलोड के साइज़ की पुष्टि करने के साथ-साथ अनुरोध में Content-Encoding हेडर भेजा गया.

      2. यह देखने के लिए जांच करें कि क्या पेलोड का असंपीडित आकार Apigee Edge में अनुमति की सीमा

         अनुरोध का सैंपल:

         curl https://<hostalias>/testtoobigbody -k -X POST -F file=@test15mbfile.gz -H "Content-Encoding: gzip" -v
         

         ऊपर दिए गए मामले में, फ़ाइल test15mbfile.gz का साइज़ तय सीमा से कम है; हालांकि, कंप्रेस की गई फ़ाइल test15mbfile का साइज़ ~15 एमबी है और Content-Encoding हेडर, gzip है.

         अगर किसी दूसरे क्लाइंट का इस्तेमाल किया जा रहा है, तो पेलोड के साइज़ का पता लगाने के लिए, क्लाइंट लॉग पाएं भेजा जा रहा है और अगर Content-Encoding हेडर को gzip पर सेट किया गया है.

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

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

   1. अगर आप निजी क्लाउड उपयोगकर्ता हैं, तो यह तय करने के लिए कि मैसेज प्रोसेसर के लॉग का इस्तेमाल किया जा सकता है एचटीटीपी 413 की गड़बड़ियों के बारे में अहम जानकारी.

   2. मैसेज प्रोसेसर के लॉग देखें:

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

   3. यह देखने के लिए खोजें कि किसी विशेष अवधि के दौरान कोई 413 गड़बड़ी हुई है या नहीं (अगर में हुई गड़बड़ी) या अगर 413 के साथ अब भी कोई अनुरोध पूरा नहीं हो पा रहा है.

      इन खोज स्ट्रिंग का इस्तेमाल किया जा सकता है:

      grep -ri "chunkCount"
      

      grep -ri "RequestTooLarge"
      

   4. आपको system.log से मिलती-जुलती लाइनें मिलेंगी (आपके मामले में TotalRead और chunkCount अलग हो सकते हैं):

      2021-07-06 13:29:57,544  NIOThread@1 ERROR HTTP.SERVICE -
        TrackingInputChannel.checkMessageBodyTooLarge()
        : Message is too large.  TotalRead 10489856 chunkCount 2570
      
      2021-07-06 13:29:57,545  NIOThread@1 INFO  HTTP.SERVICE -
        ExceptionHandler.handleException()
        : Exception trace: com.apigee.errors.http.user.RequestTooLarge
        : Body buffer overflow
      

   5. डीकंप्रेशन की प्रोसेस के दौरान, जैसे ही मैसेज प्रोसेसर, कुल कीमत का पता लगाता है रीड बाइट है > 10 एमबी तक हो जाता है, तो यह रुक जाता है और नीचे दी गई लाइन को प्रिंट कर देता है:

      Message is too large.  TotalRead 10489856 chunkCount 2570
      

      अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

      इसका मतलब है कि अनुरोध पेलोड का साइज़ 10 एमबी से ज़्यादा है और Apigee थ्रो गड़बड़ी RequestTooLarge जब साइज़ 10 एमबी की तय सीमा से ज़्यादा होना शुरू हो जाता है protocol.http.TooBigBody के रूप में गड़बड़ी कोड के साथ

रिज़ॉल्यूशन

सीमाएं

Apigee को चाहिए कि क्लाइंट ऐप्लिकेशन और बैकएंड सर्वर इससे ज़्यादा पेलोड साइज़ न भेजे Request/response size के लिए दस्तावेज़ के अनुसार अनुमत सीमा Apigee Edge की सीमाएं.

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

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

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

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

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

2. ऊपर दिए गए निर्देश का सैंपल नतीजा कुछ इस तरह है:

   /opt/apigee/edge-message-processor/conf/http.properties:HTTPRequest.body.buffer.limit=10m
   

   अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

3. ऊपर दिए गए उदाहरण में, ध्यान दें कि प्रॉपर्टी HTTPRequest.body.buffer.limit को 10m मान के साथ सेट कर दिया गया है http.properties.

   इससे पता चलता है कि Apigee for Private में कॉन्फ़िगर किए गए पेलोड साइज़ की सीमा की सीमा क्या है क्लाउड का साइज़ 10 एमबी है.

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

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

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

अगर आप सार्वजनिक क्लाउड के उपयोगकर्ता हैं, तो यह जानकारी दें:

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

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

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