415 असमर्थित मीडिया प्रकार - असमर्थित एन्कोडिंग

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

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

क्लाइंट ऐप्लिकेशन को एपीआई कॉल के रिस्पॉन्स के तौर पर, गड़बड़ी कोड protocol.http.UnsupportedEncoding के साथ 415 Unsupported Media Type का एचटीटीपी स्टेटस कोड मिलता है.

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

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

HTTP/1.1 415 Unsupported Media Type

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

{
   "fault":{
      "faultstring":"Unsupported Encoding \"UTF-8\"",
      "detail":{
         "errorcode":"protocol.http.UnsupportedEncoding"
      }
   }
}

संभावित कारण

यह गड़बड़ी तब होती है, जब क्लाइंट के भेजे गए Apigee को भेजे गए एचटीटीपी अनुरोध या Apigee को मिले एचटीटीपी रिस्पॉन्स में, Content-Encoding हेडर की वैल्यू में Apigee से मिले एचटीटीपी रिस्पॉन्स में बताई गई वैल्यू को शामिल न किया गया हो. ऐसा तब होता है, जब आरएफ़सी 7231 के सेक्शन 6.5.13: 415 काम न करने वाले मीडिया टाइप के निर्देशों के मुताबिक, एन्कोडिंग काम करती हो.

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

वजह ब्यौरा समस्या हल करने के लिए निर्देश
अनुरोध में, कोड में बदलने के तरीके का इस्तेमाल नहीं किया गया अनुरोध के हेडर Content-Encoding में कोड में बदलने का तरीका मौजूद है, जो Apigee Edge पर काम नहीं करता है. Edge के सार्वजनिक और निजी क्लाउड के उपयोगकर्ता
जवाब में, कोड में बदलने के तरीके का इस्तेमाल नहीं किया गया बैकएंड सर्वर के रिस्पॉन्स हेडर Content-Encoding में, कोड में बदलने का तरीका बताया गया है, जो Apigee Edge पर काम नहीं करता. Edge के सार्वजनिक और निजी क्लाउड के उपयोगकर्ता

निदान के सामान्य चरण

गड़बड़ी का पता लगाने के लिए, इनमें से किसी भी तरीके का इस्तेमाल किया जा सकता है:

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

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

  1. अपने Apigee Edge खाते में साइन इन करें.
  2. उस संगठन पर जाएं जिसमें आपको समस्या की जांच करनी है:

    यूज़र इंटरफ़ेस (यूआई) संगठन का ड्रॉप-डाउन
  3. विश्लेषण करें > एपीआई की निगरानी करना > जांच करें पेज पर जाएं.
  4. वह खास समयसीमा चुनें जिसमें आपने गड़बड़ियां देखी थीं.
  5. पक्का करें कि प्रॉक्सी फ़िल्टर सभी पर सेट है.
  6. समय के हिसाब से गलत कोड प्लॉट करें.
  7. वह सेल चुनें जिसमें गड़बड़ी कोड protocol.http.UnsupportedEncoding है, जैसा कि नीचे दिखाया गया है:

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

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

  10. लॉग विंडो से, नीचे दी गई जानकारी पर ध्यान दें:
    • गड़बड़ी का सोर्स: इससे पता चलता है कि apigee या target से गड़बड़ी मिली है.
    • गलत कोड: यह protocol.http.UnsupportedEncoding से मेल खाना चाहिए.
  11. अगर गलत सोर्स apigee है, तो इससे पता चलता है कि अनुरोध के Content-Encoding हेडर में, कोड में बदलने का काम नहीं किया जा सकता.
  12. अगर फ़ॉल्ट सोर्स target है, तो इससे पता चलता है कि बैकएंड सर्वर के रिस्पॉन्स में, Content-Encoding हेडर में शामिल कोड में बदलने का तरीका काम नहीं करता.

ट्रेस टूल

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

  1. ट्रेस सेशन को चालू करें और इनमें से कोई एक तरीका अपनाएं:
    • 415 Unsupported Media Type गड़बड़ी आने तक इंतज़ार करें या
    • अगर समस्या को फिर से देखा जा सकता है, तो 415 Unsupported Media Type गड़बड़ी को फिर से दिखाने के लिए एपीआई कॉल करें.
  2. पक्का करें कि सभीflowInfos दिखाएं चालू हैं:

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

  6. ट्रेस में से गड़बड़ी की वैल्यू नोट करें.

    ऊपर दिया गया सैंपल ट्रेस, गड़बड़ी को Unsupported Encoding "utf-8" के तौर पर दिखाता है. बैकएंड सर्वर को अनुरोध भेजने के बाद, Apigee ने गड़बड़ी की जानकारी दी है. इससे पता चलता है कि बैकएंड सर्वर ने रिस्पॉन्स हेडर Content-Encoding को "utf-8" की वैल्यू के साथ भेजा. यह Apigee में, कोड में बदलने का तरीका नहीं है.

  7. ट्रेस में AX (Analytics डेटा रिकॉर्ड किया गया) फ़ेज़ पर जाएं और उस पर क्लिक करें.
  8. चरण का ब्यौरा पैनल में गड़बड़ी / रिस्पॉन्स हेडर सेक्शन तक नीचे स्क्रोल करके X-Apigee-fault-code और X-Apigee-fault-source के मान तय करें, जैसा कि नीचे दिखाया गया है:

  9. आपको X-Apigee-fault-code और X-Apigee-fault-source की वैल्यू, protocol.http.UnsupportedEncoding और target के तौर पर दिखेंगी. इससे पता चलता है कि यह गड़बड़ी इसलिए हुई थी, क्योंकि रिस्पॉन्स हेडर Content-Encoding में बैकएंड सर्वर ने "utf-8" की, इस्तेमाल न की जा सकने वाली एन्कोडिंग वैल्यू को पास किया था.

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

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

    2. इससे टारगेट सर्वर को भेजे गए अनुरोध के लिए कर्ल विंडो खुलती है. यहां से टारगेट सर्वर के होस्ट का उपनाम तय किया जा सकता है.
    3. अगर टारगेट सर्वर होस्ट का उपनाम किसी वर्चुअल होस्ट उपनाम की ओर इशारा कर रहा है, तो इसका मतलब है प्रॉक्सी चेन. ऐसे में, आपको चेन वाली प्रॉक्सी के लिए ऊपर दिए गए सभी चरणों को दोहराना होगा. आपको इन सभी चरणों को तब तक दोहराना होगा, जब तक कि आपको यह पता न चल जाए कि 415 Unsupported Media Type गड़बड़ी की वजह असल में क्या हो रही है.
    4. अगर टारगेट सर्वर होस्ट का उपनाम आपके बैकएंड सर्वर को पॉइंट करता है, तो इसका मतलब है कि आपका बैकएंड सर्वर, काम न करने वाले कोड को Apigee को पास कर रहा है.

Nkinix ऐक्सेस लॉग

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

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

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

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

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

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

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

    X-Apigee-fault-source का वैल्यू target भी हो सकता है.

वजह: अनुरोध में, कोड में बदलने का अनुरोध काम नहीं कर रहा है

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

  1. एपीआई मॉनिटरिंग या NGINX ऐक्सेस लॉग का इस्तेमाल करके मिली गड़बड़ी के लिए, फ़ॉल कोड और फ़ॉल सोर्स तय करें. इसके बारे में गड़बड़ी की जानकारी पाने के सामान्य तरीके में बताया गया है.
  2. अगर गलत कोड protocol.http.UnsupportedEncoding है और गलत सोर्स की वैल्यू apigee या MP है, तो इससे पता चलता है कि क्लाइंट ऐप्लिकेशन के भेजे गए अनुरोध में, अनुरोध के हेडर में Content-Encoding को कोड में बदलने का इस्तेमाल नहीं किया जा सकता.
  3. एचटीटीपी अनुरोध के एक हिस्से के तौर पर पास की गई, इस्तेमाल नहीं की जा सकने वाली एन्कोडिंग की वैल्यू तय की जा सकती है. इसके लिए, इनमें से किसी एक तरीके का इस्तेमाल किया जा सकता है:

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

    गड़बड़ी के मैसेज का इस्तेमाल करके:
    1. अगर आपके पास Apigee Edge से मिले गड़बड़ी के पूरे मैसेज का ऐक्सेस है, तो faultstring देखें. faultstring में, इस्तेमाल न किए जा सकने वाले एंडकोडिंग की वैल्यू शामिल होती है.

      गड़बड़ी के मैसेज का उदाहरण:

      "faultstring":"Unsupported Encoding \"UTF-8\""
      
    2. ऊपर दिए गए गड़बड़ी के मैसेज में, ध्यान दें कि इस्तेमाल नहीं की जा सकने वाली एन्कोडिंग की वैल्यू “UTF-8” है, जैसा कि faultstring में दिखाया गया है.

      Apigee Edge में, “UTF-8” कोड में बदलने का तरीका नहीं है, इसलिए यह अनुरोध इस गड़बड़ी कोड के साथ 415 Unsupported Media Type गड़बड़ी की वजह से फ़ेल हो गया: protocol.http.UnsupportedEncoding.

    वास्तविक अनुरोध

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

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

        curl -v "https://HOSTALIAS/v1/testgzip" -H "Content-Encoding: UTF-8" -X POST -d @request_payload.gz
        

        अनुरोध का ऊपर दिया गया उदाहरण, Content- Encoding हेडर में "UTF-8" वैल्यू भेजता है. यह Apigee Edge में कोड में बदलने के तरीके के तौर पर काम नहीं करता. इसलिए, गड़बड़ी कोड: protocol.http.UnsupportedEncoding के साथ 415 Unsupported Media Type गड़बड़ी होने की वजह से यह अनुरोध पूरा नहीं हो पाता.

रिज़ॉल्यूशन

  1. काम करने वाली एन्कोडिंग में Apigee के साथ काम करने वाली एन्कोडिंग की सूची देखें.
  2. पक्का करें कि क्लाइंट ऐप्लिकेशन हमेशा यह जानकारी भेजे:
    • अनुरोध में, Content-Encoding हेडर की वैल्यू के तौर पर सिर्फ़ इस्तेमाल की जा सकने वाली एन्कोडिंग
    • अनुरोध पेलोड, Apigee Edge के साथ काम करने वाले फ़ॉर्मैट में और Content-Encoding हेडर में दिए गए फ़ॉर्मैट से मेल खाता है
  3. ऊपर दिए गए उदाहरण में, अनुरोध पेलोड में एक gz एक्सटेंशन है जो बताता है कि कॉन्टेंट का फ़ॉर्मैट gzip होना चाहिए. इस समस्या को ठीक करने के लिए, अनुरोध के हेडर को Content-Encoding: gzip के तौर पर और अनुरोध पेलोड को gzip फ़ॉर्मैट में भेजें:

    curl -v "https://HOSTALIAS/v1/testgzip" -H "Content-Encoding: gzip" -X POST -d @request_payload.gz
    

वजह: कोड में बदलने के तरीके का इस्तेमाल नहीं किया जा सकता

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

  1. एपीआई मॉनिटरिंग, ट्रेस टूल या NGINX ऐक्सेस लॉग का इस्तेमाल करके मिली गड़बड़ी के लिए, फ़ॉल कोड और गलत सोर्स का पता लगाएं. डाइग्नोस्टिक के सामान्य तरीके में बताया गया है.
  2. अगर गलत सोर्स की वैल्यू target है, तो इससे पता चलता है कि बैकएंड सर्वर से भेजे गए रिस्पॉन्स में, Content-Encoding हेडर में, कोड में बदलाव करने का विकल्प काम नहीं करता.
  3. बैकएंड सर्वर से एचटीटीपी रिस्पॉन्स के तौर पर पास किए गए, काम न करने वाले कोड में बदलने के तरीके की वैल्यू तय की जा सकती है. इसके लिए, इनमें से किसी एक तरीके का इस्तेमाल किया जा सकता है:

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

    गड़बड़ी के मैसेज का इस्तेमाल करके:
    1. अगर आपके पास Apigee Edge से मिले गड़बड़ी के पूरे मैसेज का ऐक्सेस है, तो faultstring देखें. faultstring में काम न करने वाले कोड में बदलने के तरीके की वैल्यू शामिल होती है.

      गड़बड़ी के मैसेज का सैंपल:

      "faultstring":"Unsupported Encoding \"UTF-8\""
      
    2. ऊपर दिए गए गड़बड़ी के मैसेज में, ध्यान दें कि इस्तेमाल नहीं की जा सकने वाली एन्कोडिंग की वैल्यू “UTF-8” है, जैसा कि faultstring में दिखाया गया है.

      Apigee Edge में, “UTF-8” कोड में बदलने का तरीका नहीं है. इसलिए, यह अनुरोध इस गड़बड़ी कोड के साथ 415 Unsupported Media Type गड़बड़ी की वजह से पूरा नहीं हो सका: protocol.http.UnsupportedEncoding.

    ट्रेस टूल

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

रिज़ॉल्यूशन

  1. काम करने वाली एन्कोडिंग में, Apigee के साथ काम करने वाली एन्कोडिंग की सूची देखें
  2. पक्का करें कि बैकएंड सर्वर हमेशा यह जानकारी भेजता हो:
    • अनुरोध में, Content-Encoding हेडर के लिए वैल्यू के तौर पर सिर्फ़ कोड में बदलने का तरीका
    • रिस्पॉन्स पेलोड, Apigee Edge के साथ काम करने वाले फ़ॉर्मैट में और Content-Encoding हेडर में दिए गए फ़ॉर्मैट से मेल खाता है

काम करने वाली एन्कोडिंग

इस टेबल में बताया गया है कि कोड में बदलने के किस फ़ॉर्मैट का इस्तेमाल किया जा सकता है, जो Apigee Edge पर काम करता है:

हेडर एन्कोडिंग ब्यौरा
Content-Encoding gzip Unix gzip फ़ॉर्मैट
deflate इस फ़ॉर्मैट में, डिलेट कंप्रेशन एल्गोरिदम के साथ zlib स्ट्रक्चर का इस्तेमाल किया जाता है.

खास जानकारी

Apigee, आरएफ़सी के इन निर्देशों के मुताबिक, 415 Unsupported Media Type की गड़बड़ी का जवाब देता है:

खास जानकारी
आरएफ़सी 7231, सेक्शन 6.5.13: 415 काम न करने वाला मीडिया टाइप

इन बातों का ध्यान रखें

निम्न पर ध्यान दें:

  • अगर एपीआई अनुरोध के हिस्से के तौर पर, Content-Encoding हेडर में काम न करने वाला कोड भेजने की वजह से Apigee से 415 गड़बड़ी मिलती है, तो:
    • आपके पास इस तरह के अनुरोधों के लिए ट्रेस कैप्चर करने का विकल्प नहीं होगा.
    • Apigee Edge के भेजे गए गड़बड़ी के जवाब के फ़ॉर्मैट या कॉन्टेंट में बदलाव नहीं किया जा सकता. ऐसा करने के लिए, दर्शाने के लिए बच्चों के बीच में

    ऐसा इसलिए होता है, क्योंकि यह गड़बड़ी किसी भी नीति को लागू करने से पहले, मैसेज प्रोसेसर में शुरुआती चरण में होती है.

  • अगर आपके बैकएंड सर्वर से मिले रिस्पॉन्स हेडर में, काम न करने वाली एन्कोडिंग पास होने की वजह से Apigee से 415 गड़बड़ी दिखती है, तो इस गड़बड़ी से बचने के लिए बैकएंड सर्वर में, इस गड़बड़ी को ठीक करना होगा. इस समस्या को ठीक करने के लिए, कृपया अपनी बैकएंड टीम के साथ काम करें.

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

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

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

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

  • संगठन का नाम
  • परिवेश का नाम
  • एपीआई प्रॉक्सी का नाम
  • 415 गड़बड़ी को फिर से दिखाने के लिए, पूरे 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