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. वाले उपयोगकर्ता के तौर पर, 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: बिना कंप्रेस किए गए फ़ॉर्म में पेलोड का अनुरोध करें

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

    • कॉन्टेंट-एन्कोडिंग: मौजूद नहीं है
    • कॉन्टेंट की अवधि: 15360204

    संपीडित

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

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

    • कॉन्टेंट को कोड में बदलने का तरीका: gzip
    • कॉन्टेंट की अवधि: 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 के ज़रिए 413 गड़बड़ी, इसके तहत क्यों वापस आती है ये दो स्थितियां हैं, जो client.received.content.length वैरिएबल की वैल्यू पर आधारित हैं:
    स्थिति Client.received.content.length की वैल्यू गड़बड़ी की वजह
    बिना कंप्रेस किए गए फ़ॉर्मैट में पेलोड का अनुरोध करें ~15 एमबी आकार > 10 एमबी से ज़्यादा की नहीं होनी चाहिए.
    कंप्रेस किए गए फ़ॉर्मैट में पेलोड का अनुरोध करें ~10 एमबी

    संपीड़न हटाने पर आकार सीमा पार हो गई

NGINX

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

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

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

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

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

    असंपीडित

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

    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-source:

    रिस्पॉन्स हेडर मान
    X-Apigee-fault-code protocol.http.TooBigBody
    X-Apigee-fault-source policy

    अनुरोध की लंबाई 15264 (14.9 K < अनुमति दी गई सीमा) पर ध्यान दें

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

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

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

  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 एमबी से ज़्यादा हो, सीमा हो जाती है, तो यह आगे होने वाले कंप्रेशन को बंद कर देती है और फिर से जवाब देती है गड़बड़ी कोड के साथ 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 के रूप में गड़बड़ी कोड के साथ

रिज़ॉल्यूशन

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

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

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

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

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

    curl https://<host>/testtoobigbody -k -X POST -F file=@test5mbfile -v
  3. अगर यह ज़रूरी है और आपको तय सीमा से ज़्यादा बार अनुरोध/पेलोड भेजना है, तो यहां जाएं को चुनें.

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

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

10 एमबी से बड़े पेलोड के लिए, Apigee, Apigee Javaकॉलआउट, जिसे Edge कॉलआउट: GitHub पर साइन किए गए यूआरएल जनरेटर का उदाहरण.

स्ट्रीमिंग

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

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

CwC

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

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

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

सीमाएं

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