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

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

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

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

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

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

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. सही भूमिका वाले उपयोगकर्ता के तौर पर, Apigee Edge के यूज़र इंटरफ़ेस (यूआई) में साइन इन करें.

  2. उस संगठन पर जाएं जिसमें आपको समस्या की जांच करनी है

  3. विश्लेषण करें > एपीआई की निगरानी करना > जांच करें पेज पर जाएं.
  4. वह खास समयसीमा चुनें जिसमें आपने गड़बड़ियां देखी थीं.
  5. गड़बड़ी वाले कोड को सटीक बनाने के लिए, प्रॉक्सी फ़िल्टर को चुना जा सकता है.
  6. समय के हिसाब से गलत कोड प्लॉट करें.

  7. वह सेल चुनें जिसमें गलत कोड protocol.http.TooBigBody और स्थिति कोड 413 हैं, जैसा कि यहां दिखाया गया है:

  8. गड़बड़ी कोड protocol.http.TooBigBody के बारे में जानकारी नीचे दिखाई गई है:

  9. लॉग देखें पर क्लिक करें और पूरे न हो पाने वाले अनुरोध की लाइन को बड़ा करें. इसके बाद, लॉग विंडो से, नीचे दिखाई गई जानकारी पर ध्यान दें :

    असंकुचित

    स्थिति #1: बिना कंप्रेस किए गए फ़ॉर्म में पेलोड का अनुरोध भेजा गया

    लॉग विंडो से, नीचे दी गई जानकारी पर ध्यान दें:

    • स्थिति कोड: 413
    • गलत इस्तेमाल का सोर्स: proxy
    • गलत कोड: protocol.http.TooBigBody.
    • अनुरोध की लंबाई(बाइट): 15360440 (~15 एमबी)

    अगर गलत सोर्स की वैल्यू proxy है, फ़ॉल कोड की वैल्यू protocol.http.TooBigBody है, और अनुरोध की अवधि 10 एमबी से ज़्यादा है, तो इससे पता चलता है कि क्लाइंट के एचटीटीपी अनुरोध का अनुरोध पेलोड साइज़, Apigee में स्वीकार की गई सीमा से ज़्यादा है.

    संपीडित

    स्थिति #2: कंप्रेस किए गए फ़ॉर्म में पेलोड का अनुरोध भेजा गया

    लॉग विंडो से, नीचे दी गई जानकारी पर ध्यान दें:

    • स्थिति कोड: 413
    • गलत इस्तेमाल का सोर्स: proxy
    • गलत कोड: protocol.http.TooBigBody.
    • अनुरोध की लंबाई(बाइट): 15264 (~15kB)

    अगर गलत सोर्स की वैल्यू proxy है, गलत कोड की वैल्यू protocol.http.TooBigBody है, और अनुरोध की अवधि 10 एमबी से कम है, तो इससे पता चलता है कि क्लाइंट के एचटीटीपी अनुरोध का अनुरोध पेलोड साइज़, कंप्रेस किए गए फ़ॉर्मैट में तय सीमा से कम है. हालांकि, Apigee से अनकंप्रेस किए जाने पर, पेलोड का साइज़ तय सीमा से ज़्यादा है.

ट्रेस

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

  1. ट्रेस सेशन को चालू करें या फिर
    • 413 Request Entity Too Large गड़बड़ी आने तक इंतज़ार करें या
    • अगर समस्या को फिर से देखा जा सकता है, तो एपीआई कॉल करें और 413 Request Entity Too Large गड़बड़ी फिर से दिखाएं

  2. पक्का करें कि फ़्लो की सभी जानकारी दिखाएं चालू है.

  3. सफल न होने वाले अनुरोधों में से किसी एक को चुनें और ट्रेस की जांच करें.
  4. क्लाइंट से मिला अनुरोध चरण पर जाएं.

    असंकुचित

    स्थिति #1: बिना कंप्रेस किए गए फ़ॉर्म में पेलोड का अनुरोध भेजा गया

    नीचे दी गई जानकारी का ध्यान रखें:

    • कॉन्टेंट को कोड में बदलने का तरीका: मौजूद नहीं है
    • Content-Length: 15360204

    संपीडित

    स्थिति #2: कंप्रेस किए गए फ़ॉर्म में पेलोड का अनुरोध भेजा गया

    नीचे दी गई जानकारी का ध्यान रखें:

    • कॉन्टेंट को कोड में बदलने का तरीका: gzip
    • Content-Length: 14969
    • कॉन्टेंट किस तरह का है: application/x-gzip
  5. ट्रेस के अलग-अलग फ़ेज़ में नेविगेट करें और पता लगाएं कि गड़बड़ी कहां हुई थी.

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

  7. ट्रेस में से गड़बड़ी की वैल्यू नोट करें. ऊपर दिए गए सैंपल ट्रेस में ये चीज़ें शामिल हैं:
    • गड़बड़ी: Body buffer overflow
    • error.class: com.apigee.errors.http.user.RequestTooLarge

  8. क्लाइंट को भेजा गया जवाब पर जाएं और ट्रेस से गड़बड़ी की वैल्यू नोट करें. नीचे दिया गया सैंपल ट्रेस:

    • गड़बड़ी: 413 Request Entity Too Large
    • गड़बड़ी वाला कॉन्टेंट: {"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}
  9. ट्रेस में AX (Analytics डेटा रिकॉर्ड किया गया) फ़ेज़ पर जाएं और इस पर क्लिक करें.

  10. चरण का ब्यौरा सेक्शन में, नीचे की ओर स्क्रोल करके वैरिएबल रीड पर जाएं.

  11. वैरिएबल client.received.content.length की वैल्यू तय करें, जिससे पता चलता है:
    • अनुरोध पेलोड का असल साइज़, जब इसे बिना कंप्रेस किए फ़ॉर्मैट में भेजा जाता है और
    • जब पेलोड को कंप्रेस किए गए फ़ॉर्मैट में भेजा जाता है, तब Apigee के ज़रिए डेटा कंप्रेस करने पर, अनुरोध वाले पेलोड का साइज़. इस मामले में यह हमेशा, तय सीमा (10 एमबी) की वैल्यू के जैसी ही होगी.

    असंकुचित

    स्थिति #1: कंप्रेस किए बिना पेलोड का अनुरोध करना

    client.received.content.length वैरिएबल: 15360204

    संपीडित

    स्थिति #2: कंप्रेस किए गए फ़ॉर्मैट में पेलोड का अनुरोध करना

    client.received.content.length वैरिएबल: 10489856

  12. इस टेबल में बताया गया है कि Apigee से, client.received.content.length वैरिएबल की वैल्यू के आधार पर दो स्थितियों में 413 गड़बड़ी क्यों दिखाई गई है:
    स्थिति client.received.content.length की वैल्यू सफल न होने की वजह
    असंपीड़ित फ़ॉर्मैट में पेलोड का अनुरोध करें ~15 एमबी साइज़ > 10 एमबी से ज़्यादा नहीं होना चाहिए.
    कंप्रेस किए गए फ़ॉर्मैट में पेलोड का अनुरोध करें ~10 एमबी

    डीकंप्रेस करते समय साइज़ तय सीमा से ज़्यादा हो गया है

NGINX

NGINX ऐक्सेस लॉग का इस्तेमाल करके, गड़बड़ी का पता लगाने के लिए:

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

  2. NGINX ऐक्सेस लॉग देखें:

    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

  3. यह देखें कि किसी खास अवधि के दौरान 413 से जुड़ी कोई गड़बड़ी तो नहीं हुई है (अगर समस्या पहले हुई थी) या क्या 413 से जुड़े कोई अनुरोध अब भी पूरे नहीं हो पा रहे हैं.
  4. अगर आपको X-Apigee-fault-code की वैल्यू, protocol.http.TooBigBody से मेल खाने वाली कोई 413 गड़बड़ी मिलती है, तो X-Apigee-fault-source की वैल्यू तय करें.

    असंकुचित

    स्थिति #1 : बिना कंप्रेस किए गए फ़ॉर्मैट में पेलोड के साइज़ का अनुरोध करना

    NGINX ऐक्सेस लॉग की ऊपर दी गई सैंपल एंट्री में X-Apigee-fault-code और X-Apigee-fault-code के लिए ये वैल्यू दी गई हैं:

    रिस्पॉन्स हेडर वैल्यू
    X-Apigee-fault-code protocol.http.TooBigBody
    X-Apigee-fault-sourc policy

    अनुरोध की अवधि: 15360440 (14.6 एमबी > मंज़ूर की गई सीमा) देखें

    संपीडित

    स्थिति #2 : कंप्रेस किए गए फ़ॉर्मैट में पेलोड के साइज़ का अनुरोध करना

    NGINX ऐक्सेस लॉग की ऊपर दी गई सैंपल एंट्री में X-Apigee-fault-code और X-Apigee-fault-code के लिए ये वैल्यू दी गई हैं:

    रिस्पॉन्स हेडर वैल्यू
    X-Apigee-fault-code protocol.http.TooBigBody
    X-Apigee-fault-source policy

    अनुरोध की लंबाई पर ध्यान दें:15264 (14.9 हज़ार < अनुमत सीमा)

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

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

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

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

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

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

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

रिज़ॉल्यूशन

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

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

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

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

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

    ट्रेस

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

    1. अगर आपने पूरे न होने वाले अनुरोध के लिए कोई ट्रेस कैप्चर किया है, तो ट्रेस और
        में बताए गए तरीके देखें
      1. client.received.content.length वैरिएबल की वैल्यू तय करें
      2. पुष्टि करें कि क्लाइंट के अनुरोध में Content-Encrypt: gzip हेडर शामिल है या नहीं
    2. अगर client.received.content.length वैरिएबल की वैल्यू 10 एमबी, अनुमति की सीमा, और अनुरोध हेडर के Content-एन्कोडिंग: 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 पर सेट किया गया है या नहीं.

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

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

    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 एमबी से ज़्यादा है और जब साइज़ 10 एमबी की सीमा से ज़्यादा होता है, तो Apigee गड़बड़ी RequestTooLarge बताता है. साथ ही, गड़बड़ी का कोड protocol.http.TooBigBody होता है

रिज़ॉल्यूशन

साइज़ ठीक करें

पहला विकल्प [सुझाया गया]: क्लाइंट ऐप्लिकेशन की समस्या को ठीक करें, ताकि पेलोड का साइज़ तय सीमा से ज़्यादा न भेजा जाए

  1. किसी क्लाइंट की ओर से अनुरोध / पेलोड का साइज़, सीमाओं में दी गई सीमा से ज़्यादा होने की वजह का विश्लेषण करें.

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

    ऊपर दिए गए उदाहरण में, छोटे साइज़ की फ़ाइल पास करके समस्या को ठीक किया जा सकता है. मान लें कि test5mbfile (5 एमबी तक का) पेलोड है, जैसा कि यहां दिखाया गया है: 

    curl https://<host>/testtoobigbody -k -X POST -F file=@test5mbfile -v

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

हस्ताक्षर किए गए यूआरएल पैटर्न

विकल्प #2 [सुझाया गया]: Apigee Java कॉलआउट में, साइन किए गए यूआरएल पैटर्न का इस्तेमाल करें

10 एमबी से बड़े पेलोड के लिए, Apigee, Apigee Java कॉलआउट में, साइन किए हुए यूआरएल पैटर्न का इस्तेमाल करने का सुझाव देता है. इसे GitHub पर एज कॉलआउट: साइन किया गया यूआरएल जनरेटर उदाहरण से दिखाया गया है.

स्ट्रीमिंग

तीसरा विकल्प : स्ट्रीमिंग की सुविधा का इस्तेमाल करना

अगर आपके एपीआई प्रॉक्सी को बहुत बड़े अनुरोधों और/या जवाबों को मैनेज करना है, तो आप Apigee में स्ट्रीमिंग चालू कर सकते हैं.

CwC

चौथा विकल्प : बफ़र सीमा को बढ़ाने के लिए CwC प्रॉपर्टी का इस्तेमाल करें

इस विकल्प का इस्तेमाल सिर्फ़ तब करना चाहिए, जब सुझाए गए किसी भी विकल्प का इस्तेमाल न किया जा सके. इसकी वजह यह है कि डिफ़ॉल्ट साइज़ को बढ़ाने पर परफ़ॉर्मेंस से जुड़ी समस्याएं हो सकती हैं.

Apigee, CwC प्रॉपर्टी उपलब्ध कराता है, जिसकी मदद से अनुरोध और रिस्पॉन्स पेलोड के साइज़ की सीमा बढ़ाई जा सकती है. ज़्यादा जानकारी के लिए, राऊटर या मैसेज प्रोसेसर पर मैसेज के साइज़ की सीमा सेट करना देखें

सीमाएं

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

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

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

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

  1. Message प्रोसेसर मशीन पर, /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 प्रॉपर्टी को http.properties में, 10m की वैल्यू के साथ सेट किया गया है.

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

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

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

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

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

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

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

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

  • 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