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

फ़िलहाल, Apigee Edge के दस्तावेज़ देखे जा रहे हैं.
पर जाएं Apigee X दस्तावेज़. info

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

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

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

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

HTTP/1.1 502 Bad Gateway

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

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

ये वजहें हो सकती हैं

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

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

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

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

गड़बड़ी की जानकारी इकट्ठा करने के सामान्य चरण

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

एपीआई की परफ़ॉर्मेंस मॉनिटर करना

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

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

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

NGINX

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

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

  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 के साथ कोई 502 गड़बड़ी दिखती है और इसकी वैल्यू protocol.http.DuplicateHeader से मेल खाती है, तो 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. अगर यह सही है और आपको डुप्लीकेट हेडर की अनुमति देनी है, तो CwC प्रॉपर्टी का इस्तेमाल करके दूसरा विकल्प देखें.

CwC

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

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

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

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

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

खास जानकारी

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

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

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

गड़बड़ी की जानकारी इकट्ठा करना

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

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

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

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