500 सर्वर में गड़बड़ी - बैडफ़ॉर्म डेटा

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

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

क्लाइंट ऐप्लिकेशन को 500 Internal Server Error का एचटीटीपी स्टेटस कोड मिलता है: एपीआई कॉल के रिस्पॉन्स के तौर पर गड़बड़ी कोड protocol.http.BadFormData.

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

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

HTTP/1.1 500 Internal Server Error

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

{
   "fault":{
      "faultstring":"Bad Form Data",
      "detail":{
         "errorcode":"protocol.http.BadFormData"
      }
   }
}

फ़ॉर्म डेटा

इससे पहले कि हम इस समस्या को हल करने के बारे में बात करें, आइए जानते हैं कि फ़ॉर्म डेटा क्या है.

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

फ़ॉर्म डेटा ट्रांसमिशन

  1. कॉन्टेंट-टाइप: ऐप्लिकेशन/x-www-form-urlencoded
    • अगर फ़ॉर्म डेटा का साइज़ छोटा है, तो डेटा को की-वैल्यू पेयर के तौर पर, इनके साथ भेजा जाता है:
      • दोनों कुंजियों के वर्ण यहां बताए गए नियमों के अनुसार एन्कोड किए गए हैं फ़ॉर्म - सेक्शन 17.13.4.1
      • हेडर Content-Type: application/x-www-form-urlencoded

      फ़ॉर्म डेटा के साथ अनुरोध का सैंपल:

      curl https://HOSTALIAS/somepath -H "Content-Type: application/x-www-form-urlencoded" -d "username=abc@google.com&pasword=secret123"
      
    • कुंजियों और मानों, दोनों में मौजूद गैर-अक्षर और अंक वाले वर्ण प्रतिशत के तौर पर एन्कोड किया गया. इसका मतलब है कि इन्हें वर्ण ट्रिपलेट के तौर पर दिखाया जाता है %HH, जिसमें प्रतिशत का चिह्न होता है. इसके बाद दो हेक्साडेसिमल अंक होते हैं खास वर्ण का ASCII कोड दिखाता है.
    • इसलिए, फ़ॉर्म डेटा में प्रतिशत चिह्न (%) का इस्तेमाल किया जा सकता है, लेकिन यह इसे खास एस्केप सीक्वेंस की शुरुआत के तौर पर समझा जाता है. इसलिए, अगर फ़ॉर्म डेटा को कुंजी या वैल्यू में प्रतिशत का निशान (%) है, तो इसे भेजा जाना चाहिए %25, होता है, जो प्रतिशत चिह्न का ASCII कोड दिखाता है (%) वर्ण.
  2. कॉन्टेंट-टाइप: मल्टीपार्ट/फ़ॉर्म-डेटा

    अगर आपको बड़ी मात्रा में बाइनरी डेटा या बिना ASCII वाले टेक्स्ट को ट्रांसमिट करना है तो आप वर्णों के साथ डेटा भेज सकते हैं Content-Type: मल्टीपार्ट/फ़ॉर्म-डेटा, जैसा कि यहां बताया गया है फ़ॉर्म - सेक्शन 17.13.4.2

संभावित कारण

यह गड़बड़ी तब होती है, जब ये सभी शर्तें पूरी होती हैं:

  1. क्लाइंट ने Apigee Edge को जो एचटीटीपी अनुरोध भेजा है उसमें ये चीज़ें शामिल हैं:
    1. Content-Type: application/x-www-form-urlencoded, और
    2. प्रतिशत के निशान (%) या प्रतिशत के निशान वाला फ़ॉर्म डेटा (%) के बाद अमान्य हेक्साडेसिमल वर्ण हैं फ़ॉर्म - सेक्शन 17.13.4.1.
  2. Apigee Edge में एपीआई प्रॉक्सी, किसी भी वर्ण वाले खास फ़ॉर्म पैरामीटर को पढ़ती है जिन्हें ExtractVariables या 'असाइन करें' मैसेज से जुड़ी नीति.

    उदाहरण के लिए, अगर फ़ॉर्म डेटा में प्रतिशत का निशान (%) है, जैसा कि (बिना) कोड में बदलने का तरीका) या प्रतिशत का निशान (%) इसके बाद कोई अमान्य हेक्साडेसिमल वर्ण शामिल करते हैं, तो आपको यह गड़बड़ी दिखती है.

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

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

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

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

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

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

  1. Apigee Edge के यूज़र इंटरफ़ेस (यूआई) में ऐसे उपयोगकर्ता के तौर पर साइन इन करें जिसके साथ की भूमिका होनी चाहिए.
  2. उस संगठन पर जाएं जिसमें आपको समस्या की जांच करनी है.

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

  6. वह सेल चुनें जिसमें गड़बड़ी कोड protocol.http.BadFormData है नीचे दी गई जानकारी देखें:

    (बड़ी इमेज देखें)

  7. गड़बड़ी कोड protocol.http.BadFormData के बारे में जानकारी यह है नीचे दिखाए गए तरीके से दिखाया गया है:

    (बड़ी इमेज देखें)

  8. लॉग देखें पर क्लिक करें और फ़ेल हो चुके अनुरोध की पंक्ति को बड़ा करें.

  9. लॉग विंडो में जाकर, यह जानकारी देखें:
    • स्टेटस कोड: 500
    • गलत सोर्स: proxy
    • गलत कोड: protocol.http.BadFormData
    • गड़बड़ी से जुड़ी नीति: extractvariables/EV-ExtractFormParams
  10. अगर गलत सोर्स proxy है, तो गलत कोड protocol.http.BadFormData और गलत नीति को खाली नहीं छोड़ा जा सकता. इसके बाद, यह खाली नहीं होता यह बताता है कि गड़बड़ी हुई है, जबकि गलती में बताई गई नीति नीति ऐसे फ़ॉर्म डेटा (फ़ॉर्म पैरामीटर) को पढ़ या निकाल रही थी जिसमें ऐसे वर्ण जिन्हें इस्तेमाल करने की अनुमति नहीं है.
  11. इस उदाहरण में, X-Apigee-fault-policy extractvariables/EV- ExtractFormParams, है, जिसका मतलब है कि ExtractVariables नीति को फ़ॉर्म को पढ़ते या एक्सट्रैक्ट करते समय, EV-ExtractFormParams को प्रोसेस नहीं किया जा सका पैरामीटर का इस्तेमाल करें.

ट्रेस करने वाला टूल

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

  1. ट्रेस सेशन चालू करना साथ ही:
    • 500 Internal Server Error गड़बड़ी आने तक इंतज़ार करें, या
    • अगर आपको समस्या के बारे में अच्छे से पता है, तो समस्या के बारे में बताने के लिए एपीआई कॉल करें 500 Internal Server Error अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
  2. पक्का करें कि सभी FlowInfos दिखाएं चालू है:

  3. पूरे न हो पाने वाले अनुरोधों में से किसी एक को चुनें और ट्रेस की जांच करें.
  4. ट्रेस के अलग-अलग फ़ेज़ पर नेविगेट करें और गड़बड़ी का पता लगाएं हुआ.
  5. आम तौर पर, आपको नीचे दी गई किसी एक नीति में गड़बड़ी दिखेगी:

    ऊपर दिए गए सैंपल ट्रेस में, ध्यान दें कि गड़बड़ी ExtractVariables की EV-ExtractFormParams नाम की नीति है.

  6. विफल हो गई खास नीति के बाद गड़बड़ी नाम वाले फ़्लो पर जाएं:

  7. ट्रेस में दी गई इन वैल्यू को नोट करें:

    गड़बड़ी: Bad Form Data

    राज्य: PROXY_REQ_FLOW

    error.class: com.apigee.rest.framework.BadRequestException

    • गड़बड़ी Bad Form Data की वैल्यू से पता चलता है कि फ़ॉर्म पैरामीटर में कुछ ऐसे वर्ण थे, जिनका उपयोग करने की अनुमति नहीं है.
    • राज्य की वैल्यू PROXY_REQ_FLOW, से पता चलता है कि एपीआई प्रॉक्सी के अनुरोध के फ़्लो में गड़बड़ी हुई.
  8. ट्रेस में AX (Analytics डेटा रिकॉर्ड किया गया) चरण पर जाएं और क्लिक करें इसे.
  9. नीचे स्क्रोल करते हुए चरण से जुड़ी जानकारी - गड़बड़ी हेडर सेक्शन पर जाएं और X-Apigee-fault-code, X-Apigee-fault-source की वैल्यू तय करें, और X-Apigee-fault-policy, जैसा कि यहां दिखाया गया है:

  10. ध्यान दें कि X-Apigee-fault-code और X-Apigee-fault-source की वैल्यू , क्रम से protocol.http.BadFormData और policy हैं और X-Apigee-fault-policy वाला फ़ील्ड खाली नहीं है. इससे पता चलता है कि गड़बड़ी यह तब हुआ, जब X-Apigee-fault-policy में बताई गई नीति के तहत उस फ़ॉर्म डेटा (फ़ॉर्म पैरामीटर) को पढ़ या एक्सट्रैक्ट कर रहा है जिसमें ऐसे वर्ण थे इस्तेमाल करने की अनुमति नहीं है.

    रिस्पॉन्स हेडर मान
    X-Apigee-fault-code protocol.http.BadFormData
    X-Apigee-fault-source policy
    X-Apigee-fault-policy extractvariables/EV-ExtractFormParams
  11. इस उदाहरण में, X-Apigee-fault-policy extractvariables/EV- ExtractFormParams, है, जिसका मतलब है कि ExtractVariables नीति को फ़ॉर्म पढ़ते या एक्सट्रैक्ट करते समय EV-ExtractFormParams विफल रहा पैरामीटर का इस्तेमाल करें.

NGINX

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

  1. अगर आप निजी Cloud उपयोगकर्ता हैं, तो NGINX ऐक्सेस लॉग का इस्तेमाल इन कामों के लिए किया जा सकता है एचटीटीपी 500 Internal Server Error के बारे में खास जानकारी तय करें.
  2. NGINX ऐक्सेस लॉग देखें:

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

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

    NGINX ऐक्सेस लॉग में 500 गड़बड़ी का नमूना:

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

    हेडर मान
    X-Apigee-fault-code protocol.http.BadFormData
    X-Apigee-fault-source policy
    X-Apigee-fault-policy extractvariables/EV-ExtractFormParams
  5. ध्यान दें कि X-Apigee-fault-code, X-Apigee-fault-source की वैल्यू protocol.http.BadFormData, policy क्रम से हैं और X-Apigee-fault-policy वाला फ़ील्ड खाली नहीं है. इससे पता चलता है कि गड़बड़ी यह तब हुआ,जब X-Apigee-fault-policy, में बताई गई नीति के तहत उस फ़ॉर्म डेटा (फ़ॉर्म पैरामीटर) को पढ़ या एक्सट्रैक्ट कर रहा है जिसमें ऐसे वर्ण थे इस्तेमाल करने की अनुमति नहीं है.
  6. इस उदाहरण में, X-Apigee-fault-policy extractvariables/EV- ExtractFormParams, है, जिसका मतलब है कि ExtractVariables नीति को फ़ॉर्म पढ़ते समय EV-ExtractFormParams को प्रोसेस नहीं किया जा सका पैरामीटर का इस्तेमाल करें.

वजह: अनुरोध में मौजूद फ़ॉर्म पैरामीटर में ऐसे वर्ण हैं जिनकी अनुमति नहीं है

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

  1. बताए गए तरीके से एपीआई मॉनिटरिंग, ट्रेस करने वाले टूल या NGINX ऐक्सेस लॉग का इस्तेमाल करके, 500 Internal Server Error के लिए गलत कोड, गलत सोर्स, और गलत नीति का पता लगाएं डाइग्नोस्टिक्स के सामान्य चरणों पर जाएं.
  2. अगर गलत कोड protocol.http.BadFormData है, तो गलत सोर्स के पास मान proxy या policy और गलत नीति गैर- खाली, तो इससे पता चलता है कि , में बताई गई नीति तब काम नहीं कर रही थी, जब फ़ॉर्म डेटा (फ़ॉर्म पैरामीटर) को पढ़ना या निकालना.
  3. गड़बड़ी से जुड़ी नीति में दी गई नीति की जांच करें और नीचे दी गई चीज़ों को तय करें जानकारी:
    1. सोर्स: यह पता लगाएं कि नीति, यहां से डेटा को पढ़ रही है या निकाल रही है अनुरोध या प्रतिक्रिया दें.
    2. फ़ॉर्म पैरामीटर: इससे उन फ़ॉर्म पैरामीटर का पता लगाया जाता है जिन्हें पढ़ा जा रहा है की नीति देखें.

      सैंपल #1

      सैंपल #1: ExtractVariables की नीति के तहत, फ़ॉर्म पैरामीटर एक्सट्रैक्ट करना:

            <ExtractVariables name="EV-ExtractFormParms">
               <DisplayName>EV-ExtractFormParams</DisplayName>
               <Source>request</Source>
               <FormParam name="username">
                  <Pattern ignoreCase="false">{username}</Pattern>
               </FormParam>
               <FormParam name="password">
                 <Pattern ignoreCase="false">{password}</Pattern>
               </FormParam>
               <VariablePrefix>forminfo</VariablePrefix>
             <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
            </ExtractVariables>
            

      ऊपर दी गई ExtractVariables नीति में:

      • सोर्स: request

        यह <Source> एलिमेंट से दिखाया जाता है

      • फ़ॉर्म पैरामीटर: username और password

        यह जानकारी के <Pattern> एलिमेंट से पता चलता है कि <FormParam> एलिमेंट

      इससे पता चलता है कि फ़ॉर्म पैरामीटर username और/या क्लाइंट के एचटीटीपी अनुरोध के तहत, password को पास किया गया Apigee Edge में ऐसे वर्ण हैं जिन्हें इस्तेमाल करने की अनुमति नहीं है.

      सैंपल #2

      सैंपल #2: टेस्ट मैसेज की नीति के तहत, फ़ॉर्म पैरामीटर कॉपी करना:

            <AssignMessage continueOnError="false" enabled="true" name="AM-CopyFormParams">
              <Copy source="request">
                <FormParams>
                  <FormParam name="username"/>
                  <FormParam name="password"/>
                </FormParams>
              </Copy>
              <AssignTo createNew="true" transport="http" type="request"/>
            </AssignMessage>
            

      ऊपर दी गई ExtractVariables नीति में:

      • स्रोत: request

        इसे यहां मौजूद source एट्रिब्यूट से दिखाया जाता है: <Copy> एलिमेंट

      • फ़ॉर्म पैरामीटर: username और password

        इसे यहां मौजूद name एट्रिब्यूट से दिखाया जाता है: <FormParam> एलिमेंट

      इससे पता चलता है कि फ़ॉर्म पैरामीटर username, password या ये दोनों, क्लाइंट के Apigee Edge को एचटीटीपी अनुरोध के हिस्से के तौर पर पास किए जाते हैं ऐसे वर्ण जिन्हें इस्तेमाल करने की अनुमति नहीं है.

  4. जांच करके देखें कि कहीं ऐसे वर्ण तो नहीं हैं जिन्हें रखने की अनुमति नहीं है फ़ॉर्म पैरामीटर में इस्तेमाल किए गए वर्णों की पहचान तीसरे चरण में की गई है नीचे दिए गए तरीकों में से किसी एक का इस्तेमाल करके:

    ट्रेस करने वाला टूल

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

    1. अगर आपने पूरे न हो पाने वाले अनुरोध के लिए ट्रेस कैप्चर कर लिया है, जैसा कि यहां बताया गया है डाइग्नोस्टिक्स के सामान्य चरणों को चुनें. इसके बाद, इनमें से कोई एक विकल्प चुनें पूरे न हो पाने वाले अनुरोध.
    2. अगर आपने पाया है कि फ़ॉर्म पैरामीटर में कोई भी वर्ण है जिन्हें इस्तेमाल करने की अनुमति नहीं है वे यहां एचटीटीपी अनुरोध का हिस्सा हैं तीसरा चरण चुनें. इसके बाद,
      1. क्लाइंट से मिला अनुरोध फ़ेज़ पर जाएं.
      2. नीचे चरण की जानकारी सेक्शन तक स्क्रोल करें और कॉन्टेंट का अनुरोध करें.

        ( बड़ी इमेज देखें)

      3. ऊपर दिए गए उदाहरण में, ध्यान दें कि फ़ॉर्म पैरामीटर password में प्रतिशत का चिह्न (%) होता है.
      4. प्रतिशत के निशान (%) का इस्तेमाल इसके लिए भी किया जाता है प्रतिशत को कोड में बदलने का तरीका, खास वर्णों को उसी रूप में इस्तेमाल नहीं किया जा सकता फ़ॉर्म डेटा.
      5. इसलिए, Apigee Edge इस मैसेज से जवाब देता है गड़बड़ी कोड के साथ 500 Internal Server Error protocol.http.BadFormData.

    असल अनुरोध

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

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

        सैंपल #1

        अनुरोध का सैंपल #1: अनुरोध के तहत फ़ॉर्म डेटा

        curl -X GET "https://HOSTALIAS/myproxy -H "Content-Type: application/x-www-form-urlencoded" -d "client_id=123456abc123&client_secret=c23578%ZY"
        

        इस उदाहरण में, ध्यान दें कि client_secret एलिमेंट में प्रतिशत का चिह्न (%) है, जिसके बाद अमान्य हेक्साडेसिमल वर्ण ZY.

        सैंपल #2

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

        curl -X GET "https://HOSTALIAS/myproxy -H "Content-Type: application/x-www-form-urlencoded" -d @form_data.xml
        

        form_data.xml का कॉन्टेंट:

        xml=<user><username>abc1234@google.com</username><password>qwerty12345!@#$%</password></user>
        

        इस उदाहरण में ध्यान दें कि एलिमेंट में password प्रतिशत का चिह्न (%) शामिल है, जो कि पास डेटा जैसा होता है.

    3. ऊपर दिए गए दो उदाहरणों में, एचटीटीपी अनुरोध के तहत भेजा गया फ़ॉर्म डेटा Apigee Edge में ऐसे वर्ण हैं जिन्हें इस्तेमाल करने की अनुमति नहीं है.
    4. इसलिए, Apigee Edge, 500 Internal Server Error की मदद से जवाब देता है गड़बड़ी कोड protocol.http.BadFormData के साथ.

रिज़ॉल्यूशन

  1. पक्का करें कि फ़ॉर्म डेटा या पैरामीटर की कुंजियों और वैल्यू, दोनों में खास वर्ण मौजूद हों क्लाइंट के भेजे गए एचटीटीपी अनुरोध के हिस्से के तौर पर भेजे गए कोड को, हमेशा फ़ॉर्म डेटा - app/x-www-form-urlencoded.
  2. ऊपर बताए गए उदाहरणों में, इन समस्याओं को ठीक किया जा सकता है:

    सैंपल #1

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

    मान्य का उपयोग करें हेक्साडेसिमल वर्ण, जो किसी खास वर्ण के ASCII कोड से मेल खाते हैं. उदाहरण के लिए, अगर आपको डॉलर का निशान ($) भेजना है, तो %24 का इस्तेमाल करें जैसा कि नीचे दिखाया गया है:

    curl -X GET "https://HOSTALIAS/myproxy -H "Content-Type: application/x-www-form-urlencoded" -d "client_id=123456abc123&client_secret=c23578%24"
    

    सैंपल #2

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

    curl -X GET "https://HOSTALIAS/myproxy -H "Content-Type: application/x-www-form-urlencoded" -d @form_data.xml
    

    form_data.xml का कॉन्टेंट:

    इसका इस्तेमाल करें प्रतिशत (%) चिह्न के लिए प्रतिशत-एन्कोडिंग, जो फ़ाइल को %25 जैसा कि नीचे दिखाया गया है:

    xml=<user><username>abc1234@google.com</username><password>qwerty12345!!@#$%25</password></user>
    

खास जानकारी

Apigee Edge के लिए यह ज़रूरी है कि फ़ॉर्म का डेटा, यहां दी गई जानकारी के हिसाब से भेजा जाए:

खास जानकारी
फ़ॉर्म डेटा - ऐप्लिकेशन/x-www-form-urlencoded

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

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

अगर ऊपर दिए गए निर्देशों का पालन करने के बाद भी समस्या बनी रहती है, तो यह जानकारी इकट्ठा करें और फिर Apigee Edge सहायता से संपर्क करें:

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

  • संगठन का नाम
  • परिवेश का नाम
  • एपीआई प्रॉक्सी का नाम
  • curl निर्देश को पूरा करें. इसका इस्तेमाल करके, गड़बड़ी कोड के साथ 500 Internal Server Error protocol.http.BadFormData
  • एपीआई अनुरोधों के लिए फ़ाइल ट्रेस करें

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

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

रेफ़रंस