502 गलत गेटवे - डुप्लीकेट हेडर

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

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

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

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

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

HTTP/1.1 502 Bad Gateway

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

{
   "fault":{
      "faultstring":"Duplicate Header \"Expires\"",
      "detail":{
         "errorcode":"protocol.http.DuplicateHeader"
      }
   }
}

संभावित वजहें

यह गड़बड़ी तब होती है, जब कोई ऐसा खास एचटीटीपी हेडर जिसे Apigee Edge में डुप्लीकेट होने की अनुमति नहीं है, एक जैसी या अलग-अलग वैल्यू के साथ एक से ज़्यादा बार दिखता है. यह रिस्पॉन्स, बैकएंड सर्वर से Apigee Edge को भेजे गए एचटीटीपी रिस्पॉन्स के हिस्से के तौर पर होता है.

आरएफ़सी 7230 के सेक्शन 3.2.2: फ़ील्ड ऑर्डरके मुताबिक, भेजने वाले को किसी मैसेज में एक ही फ़ील्ड नाम वाले कई हेडर फ़ील्ड तब तक जनरेट नहीं करने चाहिए, जब तक कि उस हेडर फ़ील्ड की पूरी फ़ील्ड वैल्यू को कॉमा लगाकर अलग की गई सूची के तौर पर न बताया गया हो [यानी, #(values)] या हेडर फ़ील्ड एक आम अपवाद है. अगर Apigee Edge को पता चलता है कि एक खास हेडर, जिसमें डुप्लीकेट होने की अनुमति नहीं है, तो उसे टारगेट/बैकएंड सर्वर से एचटीटीपी रिस्पॉन्स में एक से ज़्यादा बार भेजा जाता है. ऐसा होने पर, वह जवाब में 502 Bad Gateway और गड़बड़ी कोड protocol.http.DuplicateHeader के साथ रिस्पॉन्स देता है

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

वजह ब्यौरा समस्या हल करने के लिए निर्देश
जवाब में डुप्लीकेट हेडर बैकएंड सर्वर से मिलने वाले रिस्पॉन्स में डुप्लीकेट हेडर हैं. Edge के सार्वजनिक और निजी क्लाउड के उपयोगकर्ता

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

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

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

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

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

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

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

  7. वह सेल चुनें जिसमें गड़बड़ी कोड protocol.http.DuplicateHeader है, जैसा कि नीचे दिखाया गया है:

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

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

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

  9. पक्का करें कि स्थिति कोड ऊपर दिए गए उदाहरण के मुताबिक 502 हो.
  10. लॉग देखें पर क्लिक करें और पूरे न हो पाने वाले अनुरोध की लाइन को बड़ा करें.

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

    • स्थिति कोड: 502
    • गलत इस्तेमाल का सोर्स: target
    • गलत कोड: protocol.http.DuplicateHeader.
  12. गलत सोर्स target है. इससे पता चलता है कि बैकएंड सर्वर से मिले रिस्पॉन्स में डुप्लीकेट हेडर थे.

ट्रेस टूल

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

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

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

  3. सफल न होने वाले अनुरोधों में से किसी एक को चुनें और ट्रेस की जांच करें.
  4. ट्रेस के अलग-अलग फ़ेज़ में नेविगेट करें और पता लगाएं कि गड़बड़ी कहां हुई थी.

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

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

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

    ऊपर दिया गया सैंपल ट्रेस, गड़बड़ी को Duplicate Header "Expires" के तौर पर दिखाता है. बैकएंड सर्वर को अनुरोध भेजने के बाद, Apigee ने गड़बड़ी की समस्या हल की. इससे पता चलता है कि बैकएंड सर्वर ने हेडर Expires को एक से ज़्यादा बार भेजा है.

  7. ट्रेस में AX (Analytics डेटा रिकॉर्ड किया गया) फ़ेज़ पर जाएं और इस पर क्लिक करें.

  8. नीचे की ओर स्क्रोल करके, फ़ेज़ की जानकारी - रिस्पॉन्स हेडर सेक्शन पर जाएं और X-Apigee-fault-code और X-Apigee-fault-source की वैल्यू तय करें, जैसा कि यहां दिखाया गया है:

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

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

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

    1. इसका पता लगाने के लिए, सर्वर फ़ेज़ पर टारगेट के लिए भेजा गया अनुरोध पर वापस जाएं. Curl दिखाएं पर क्लिक करें.

    2. इससे टारगेट सर्वर को भेजे गए अनुरोध के लिए कर्ल विंडो खुलती है. यहां से टारगेट सर्वर के होस्ट का उपनाम तय किया जा सकता है.

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

NGINX

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

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

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

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

    कहां: ORG, ENV, और PORT# को असल वैल्यू से बदल दिया जाता है.

  3. यह देखने के लिए खोजें कि किसी खास अवधि के दौरान 502 में कोई गड़बड़ी तो नहीं है (अगर समस्या पहले हुई है) या क्या ऐसे अनुरोध हैं जो अब भी 502 में नहीं दिख रहे हैं.

  4. अगर आपको X-Apigee-fault-code में, protocol.http.DuplicateHeader की वैल्यू से मेल खाने वाली कोई 502 गड़बड़ी मिलती है, तो X-Apigee-fault-source की वैल्यू तय करें.

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

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

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

वजह: रिस्पॉन्स में डुप्लीकेट हेडर

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

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

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

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

    गड़बड़ी के मैसेज का इस्तेमाल करके:

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

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

      "faultstring":"Duplicate Header \"Expires\""
    2. गड़बड़ी के ऊपर दिए गए मैसेज में, यह देखा जा सकता है कि हेडर Expires को एक से ज़्यादा बार भेजा गया है, जैसा कि faultstring में दिखाया गया है.

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

    असल अनुरोध का इस्तेमाल करके:

    1. अगर आपके पास टारगेट सर्वर से किए गए असली अनुरोध का ऐक्सेस नहीं है, तो ट्रेस टूल का इस्तेमाल करना चरण 10.a और 10.b चरण से curl कमांड पाएं.

    2. अगर आपके पास टारगेट सर्वर ऐप्लिकेशन से किए गए असल अनुरोध का ऐक्सेस है, तो यह तरीका अपनाएं:

      1. टारगेट सर्वर को कॉल करें.

        इस उदाहरण में इस्तेमाल किए गए टारगेट सर्वर के लिए अनुरोध का सैंपल:

        curl -X GET "https://BACKEND_SERVER_HOST/response-headers?Expires=Mon%2C%2021%20June%202021%2007%3A28%3A00%20GMT&Expires=Mon%2C%2021%20June%202021%2007%3A28%3A00%20GMT" -v

      2. रिस्पॉन्स में दिख रहे हेडर की सूची की पुष्टि करें.

        इस उदाहरण में इस्तेमाल किए गए टारगेट सर्वर से रिस्पॉन्स का सैंपल:

        * ...Trimmed...
> GET /response-headers?Expires=Mon%2C%2021%20June%202021%2007%3A28%3A00%20GMT&Expires=Mon%2C%2021%20June%202021%2007%3A28%3A00%20GMT HTTP/2
> Host: BACKEND_SERVER_HOST
> User-Agent: curl/7.64.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 200
< date: Fri, 02 Jul 2021 05:29:07 GMT
< content-type: application/json
< content-length: 166
< server: gunicorn/19.9.0
< Expires: Mon, 21 June 2021 07:28:00 GMT
< Expires: Mon, 21 June 2021 07:28:00 GMT
< access-control-allow-origin: *
< access-control-allow-credentials: true
<
----<Response BODY>------
* Connection #0 to host httpbin.org left intact
* Closing connection 0

        ऊपर दिए गए उदाहरण के अनुरोध में, हेडर Expires को एक से ज़्यादा बार भेजा गया है. इसलिए, यह अनुरोध 502 Bad Gateway गड़बड़ी और गड़बड़ी कोड: protocol.http.DuplicateHeader की वजह से काम नहीं करेगा.

      3. faultstring में जिस हेडर का नाम दिखता है, अगर वह बैकएंड सर्वर के रिस्पॉन्स में एक से ज़्यादा बार दिखता है, तो इस गड़बड़ी की वजह यही है. ऊपर दिए गए मामले में, हेडर Expires एक से ज़्यादा बार भेजा गया है.

रिज़ॉल्यूशन

डुप्लिकेशन ठीक करें

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

  1. इस बात का विश्लेषण करें कि कोई खास बैकएंड सर्वर, डुप्लीकेट हेडर Expires भेजने की वजह क्या है. साथ ही, पुष्टि करें कि एपीआई प्रॉक्सी उसे स्वीकार कर सकते हैं या नहीं. ज़्यादातर मामलों में, एचटीटीपी स्पेसिफ़िकेशन RFC7230 के मुताबिक इस्तेमाल नहीं किया जा सकता.
  2. अगर ऐसा नहीं करना चाहिए, तो अपने टारगेट सर्वर ऐप्लिकेशन में बदलाव करें, ताकि डुप्लीकेट हेडर न भेजे जा सकें. ऊपर बताए गए उदाहरण में, हमें पता चला है कि हेडर Expires को एक ही वैल्यू के साथ दो बार भेजा जाता है. ऐसा करना ज़रूरी नहीं है. इस समस्या को ठीक करने के लिए, यह पक्का करें कि टारगेट सर्वर, Expires हेडर को सिर्फ़ एक बार पास करे.
  3. अगर आपको डुप्लीकेट हेडर इस्तेमाल करने की अनुमति देनी है, तो विकल्प #2 CwC प्रॉपर्टी का इस्तेमाल करना पर जाएं.

CwC

दूसरा विकल्प CwC प्रॉपर्टी का इस्तेमाल करना

Apigee, एक CwC प्रॉपर्टी उपलब्ध कराता है HTTPHeader.<HeaderName> , जिसकी मदद से क्लाइंट ऐप्लिकेशन और टारगेट सर्वर, Apigee Edge में एपीआई प्रॉक्सी को डुप्लीकेट हेडर भेज सकते हैं.

CwC प्रॉपर्टी वैल्यू
HTTPHeader.<HeaderName> allowDuplicates,multivalued

उदाहरण के लिए, नीचे दी गई प्रॉपर्टी को Message प्रोसेसर पर सेट किया जा सकता है. इससे, हेडर Expires के लिए डुप्लीकेट और एक से ज़्यादा वैल्यू सेट की जा सकेंगी. 

HTTPHeader.Expires=allowDuplicates, multiValued
  1. अगर आप प्राइवेट क्लाउड उपयोगकर्ता हैं, तो Apigee Edge को 502 Bad Gateway की गड़बड़ी होने से रोकने के लिए, प्रॉपर्टी को कॉन्फ़िगर किया जा सकता है. भले ही, अनुरोध में डुप्लीकेट हेडर शामिल हों. इसके लिए, डुप्लीकेट हेडर इस्तेमाल करने के लिए मैसेज प्रोसेसर को कॉन्फ़िगर करना तरीका बताने वाली गाइड का इस्तेमाल करें.
  2. अगर आप पब्लिक क्लाउड का इस्तेमाल करते हैं, तो अपने संगठन के लिए इस प्रॉपर्टी को कॉन्फ़िगर करने के लिए, Apigee Edge की सहायता टीम से संपर्क करें.

खास जानकारी

Apigee, 502 Bad Gateway की गड़बड़ी के जवाब के साथ जवाब देता है, क्योंकि उसे उम्मीद है कि बैकएंड सर्वर, आरएफ़सी के इन निर्देशों के मुताबिक काम करेगा:

खास जानकारी
आरएफ़सी 7230, सेक्शन 3.2.2: फ़ील्ड ऑर्डर
आरएफ़सी 7230, सेक्शन 3.2: हेडर फ़ील्ड

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

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

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

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

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