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 Public और Private Cloud के उपयोगकर्ताओं के लिए
डिकंप्रेशन के बाद, अनुरोध पेलोड का साइज़ तय सीमा से ज़्यादा है क्लाइंट ऐप्लिकेशन ने एचटीटीपी अनुरोध के हिस्से के तौर पर, Apigee Edge को कंप्रेस किए गए फ़ॉर्मैट में पेलोड भेजा है. Apigee Edge के डीकंप्रेस करने पर, पेलोड का साइज़ तय सीमा से ज़्यादा है. Edge Public और Private Cloud के उपयोगकर्ताओं के लिए

गड़बड़ी का पता लगाने के सामान्य चरण

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

एपीआई मॉनिटरिंग

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

  1. Apigee Edge के यूज़र इंटरफ़ेस (यूआई) में साइन इन करें. इसके लिए, आपके पास सही भूमिका होनी चाहिए.

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

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

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

  8. गड़बड़ी कोड protocol.http.TooBigBody के बारे में जानकारी, यहां दी गई इमेज में दिखाए गए तरीके से दिखती है:

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

    कंप्रेस नहीं किया गया

    पहली स्थिति: अनुरोध का पेलोड, बिना कंप्रेस किए भेजा गया है

    लॉग विंडो में, यह जानकारी नोट करें:

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

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

    संपीडित

    दूसरा उदाहरण: कंप्रेस किए गए फ़ॉर्म में अनुरोध पेलोड भेजा गया

    लॉग विंडो में, यह जानकारी नोट करें:

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

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

ट्रेस

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

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

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

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

    कंप्रेस नहीं किया गया

    पहली स्थिति: अनुरोध का पेलोड बिना कंप्रेस किए भेजा गया है

    इस जानकारी का ध्यान रखें:

    • Content-Encoding: मौजूद नहीं है
    • Content-Length: 15360204

    संपीडित

    दूसरा उदाहरण: कंप्रेस किए गए फ़ॉर्म में अनुरोध पेलोड भेजा गया

    इस जानकारी का ध्यान रखें:

    • Content-Encoding: gzip
    • Content-Length: 14969
    • Content-Type: 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 Data Recorded) फ़ेज़ पर जाएं और उस पर क्लिक करें.

  10. फ़ेज़ की जानकारी सेक्शन में, नीचे की ओर स्क्रोल करके वैरिएबल पढ़े गए पर जाएं.

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

    कंप्रेस नहीं किया गया

    पहला उदाहरण: अनुरोध का पेलोड, कंप्रेस नहीं किया गया है

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

    संपीडित

    दूसरा उदाहरण: कंप्रेस किए गए फ़ॉर्मैट में अनुरोध पेलोड

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

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

    डिकंप्रेशन के बाद साइज़ की सीमा से ज़्यादा हो गया

NGINX

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

  1. अगर आप Private 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 की वैल्यू, protocol.http.TooBigBodyकी वैल्यू से मेल खाने वाली 413 गड़बड़ियां मिलती हैं, तो X-Apigee-fault-source की वैल्यू का पता लगाएं.

    कंप्रेस नहीं किया गया

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

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

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

    अनुरोध की अवधि: 15360440 (14.6 एमबी > तय सीमा) पर ध्यान दें

    संपीडित

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

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

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

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

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

    ट्रेस

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

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

    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. यह पता लगाएं कि किसी क्लाइंट ने, सीमाएं में तय की गई सीमा से ज़्यादा अनुरोध क्यों भेजा या पेलोड का साइज़ तय सीमा से ज़्यादा क्यों है.

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

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

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

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

दूसरा विकल्प [सुझाया गया]: Apigee JavaCallout में, हस्ताक्षर किए गए यूआरएल के पैटर्न का इस्तेमाल करें

अगर पेलोड का साइज़ 10 एमबी से ज़्यादा है, तो Apigee का सुझाव है कि Apigee JavaCallout में, हस्ताक्षर किए गए यूआरएल के पैटर्न का इस्तेमाल करें. इसके बारे में, GitHub पर Edge Callout: Signed URL Generator उदाहरण में बताया गया है.

स्ट्रीमिंग

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

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

CwC

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

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

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

सीमाएं

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

  1. अगर आप पब्लिक क्लाउड के उपयोगकर्ता हैं, तो अनुरोध और जवाब के पेलोड के साइज़ की ज़्यादा से ज़्यादा सीमा वही होगी जो Request/response size के लिए, Apigee Edge की सीमाएं में बताई गई है.
  2. अगर आप Private 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 प्रॉपर्टी को http.properties में 10m वैल्यू के साथ सेट किया गया है.

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

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

डाइग्नोस्टिक जानकारी इकट्ठा करना ज़रूरी है

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

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

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

अगर आप Private 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