400 طلب غير صالح - تم إرسال طلب HTTP عادي إلى منفذ HTTPS

أنت تعرض مستندات Apigee Edge.
انتقل إلى مستندات Apigee X.
معلومات

المشكلة

يتلقّى تطبيق العميل الرد HTTP 400 Bad Request مع الرسالة The plain HTTP request was sent to HTTPS port

رسالة الخطأ

يحصل تطبيق العميل على رمز الاستجابة التالي:

HTTP/1.1 400 Bad Request

متبوعة بصفحة خطأ HTML أدناه:

<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
</body>
</html>

الأسباب المحتملة

السبب الوصف إرشادات استكشاف الأخطاء وإصلاحها التي تنطبق على
طلب HTTP إلى مضيف افتراضي تم ضبطه باستخدام بروتوكول أمان طبقة النقل (TLS) يرسِل العميل طلب HTTP إلى مضيف افتراضي تم ضبطه باستخدام بروتوكول أمان طبقة النقل (TLS). مستخدمو Edge Public و Private Cloud
طلب HTTP إلى نقطة نهاية هدف تم ضبطها لبروتوكول أمان طبقة النقل (TLS) طلب HTTP تم إرساله إلى خادم خلفية تم تفعيل بروتوكول أمان طبقة النقل (TLS) فيه في نقطة النهاية المستهدفة مستخدمو Edge Public و Private Cloud
ضبط غير صحيح للخادم الهدف تم إعداد الخادم الهدف باستخدام المنفذ الآمن 443 ولكن لم يتم تفعيل طبقة المقابس الآمنة. مستخدمو Edge Public و Private Cloud

السبب: طلب HTTP إلى مضيف افتراضي تم ضبطه باستخدام بروتوكول أمان طبقة النقل (TLS)

يحدث هذا الخطأ عندما يحاول عميل الاتصال بواجهة برمجة تطبيقات على Apigee وصفحة يتم تكوين المضيف الظاهري لاستخدام طبقة المقابس الآمنة (SSL) ويتلقى طلب HTTP بدلاً من ذلك.

التشخيص

نظرًا لحدوث هذه المشكلة في نقطة النهاية الشمالية وطلبات واجهة برمجة التطبيقات تخفق عند تفاعل نقطة الدخول بين تطبيق العميل وجهاز التوجيه، لا يتم تسجيل رسائل الخطأ هذه في جهاز توجيه NGINX الوصول إلى البيانات. وبالتالي، لن يتم تسجيل هذه الطلبات في أدوات مثل مراقبة واجهة برمجة التطبيقات أداة التتبع.

  1. يمكنك التحقق من طلب البيانات من واجهة برمجة التطبيقات ومعرفة ما إذا كنت ترسل طلب HTTP لاسم مضيف بديل يستخدم تم إعداد بحيث لا تقبل الطلبات إلا على المنفذ الآمن 443. إذا كان الأمر كذلك، فهو سبب المشكلة.

    نموذج طلب بيانات غير صحيح من واجهة برمجة التطبيقات:

    curl http://org-test.apigee.net:443/400-demo
    
    <html>
    <head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
    <body>
    <center><h1>400 Bad Request</h1></center>
    <center>The plain HTTP request was sent to HTTPS port</center>
    <hr><center>server</center>
    </body>
    </html>
    
  2. في نموذج الطلب أعلاه، لاحِظ أنه تم إجراء طلب HTTP إلى الاسم المستعار للمضيف myorg-test.apigee.net على المنفذ الآمن 443. وهذا هو سبب خطأ واحد (400 Bad Request).

الدقة

تحتاج إلى التحقق مما إذا كان العميل يستخدم HTTP بدلاً من HTTPs، وأن يكون الطلب الصحيح كما هو موضح أدناه:

نموذج طلب بيانات من واجهة برمجة التطبيقات:

curl https://org-test.apigee.net:443/400-demo

أو

curl https://org-test.apigee.net/400-demo
< HTTP/1.1 200 OK
< Date: Thu, 25 Feb 2021 13:01:43 GMT
< Content-Type: text/xml;charset=UTF-8
< Content-Length: 403
< Connection: keep-alive
< Server: gunicorn/19.9.0
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Credentials: true

السبب: طلب HTTP إلى نقطة نهاية هدف تم ضبطها لبروتوكول أمان طبقة النقل (TLS)

يحدث هذا الخطأ في حال ضبط طلبات HTTP بشكل غير صحيح إلى واجهة خلفية متوافقة مع بروتوكول أمان طبقة النقل (TLS) في نقطة النهاية المستهدفة للخادم الوكيل لواجهة برمجة التطبيقات.

التشخيص

اتّبِع الخطوات التالية لتشخيص الخطأ باستخدام أداة التتبُّع:

  1. فعِّل الإعداد Trace في واجهة مستخدم Apigee للخادم الوكيل لواجهة برمجة التطبيقات المتأثر.
  2. إرسال طلبات إلى الخادم الوكيل لواجهة برمجة التطبيقات
  3. اختَر أحد طلبات البيانات من واجهة برمجة التطبيقات التي تعذّر تنفيذها باستخدام رمز الاستجابة 400.
  4. انتقل خلال المراحل المختلفة وحدد مكان حدوث الفشل.
  5. ستظهر لك عادةً استجابة الخطأ 400 من خادم الخلفية. وهذا يعني أنّه ستظهر لك استجابة الخطأ 400 في المرحلة تلقّي الردّ. من الخادم الهدف كما هو موضّح أدناه:

  6. تحديد نقطة النهاية المستهدفة التي تم تقديم الطلب من خلالها من خلال النقر على AX (البيانات المسجَّلة في "إحصاءات Google") في التتبّع.

  7. لاحظ أن target.url، التي تحتوي على البروتوكول، والاسم المستعار لمضيف خادم الخلفية، وأحيانًا رقم المنفذ. المنفذ المستخدَم في عنوان URL المستهدف هو 443 لكن البروتوكول هو HTTP.
  8. راجِع تعريف نقطة النهاية المستهدَفة لفهم الإعدادات.
  9. يُرجى التحقُّق من أن مضيف خادم الخلفية آمن ويستجيب على منفذ آمن مثل 443. إذا كنت تستخدم البروتوكول كـ http في العنصر <URL>، إذًا فهو سبب هذه المشكلة.

    نموذج ضبط نقطة النهاية المستهدفة:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <TargetEndpoint name="default">
        <Description/>
        <FaultRules/>
        <PreFlow name="PreFlow">
            <Request/>
            <Response/>
        </PreFlow>
        <PostFlow name="PostFlow">
            <Request/>
            <Response/>
        </PostFlow>
        <Flows/>
        <HTTPTargetConnection>
            <Properties/>
            <URL>http://somehost.org:443/get</URL>
        </HTTPTargetConnection>
    </TargetEndpoint>
    

    يوضح المثال أعلاه أنك تستخدم بروتوكول HTTP، غير أن المنفذ المستخدم آمن المنفذ 443. يتسبب ذلك في استجابة خادم الخلفية 400 Bad Request ورسالة الخطأ The plain HTTP request was sent to HTTPS port

الدقة

  1. إذا كان خادم الخلفية آمنًا/تم تفعيل بروتوكول أمان طبقة النقل (TLS)، تأكَّد من استخدام البروتوكول https في العنصر <URL> لنقطة النهاية المستهدفة كما هو موضّح في في المثال التالي:

    نموذج ضبط نقطة النهاية المستهدفة:

    <HTTPTargetConnection>
        <Properties/>
        <URL>https://somehost.org:443/get</URL>
    </HTTPTargetConnection>
    
  2. إذا كان خادم الخلفية غير آمن، يُرجى تنفيذ ما يلي:

    • ولا تذكر رقم المنفذ الآمن، مثل 443.
    • لست مضطرًا إلى ذكر رقم المنفذ على الإطلاق، إذا كان خادم الخلفية يستمع إلى منفذ عادي غير آمن
    • اذكر رقم المنفذ إذا كنت تستخدم أي منفذ غير آمن آخر، على سبيل المثال: 9080

    نموذج ضبط نقطة النهاية المستهدفة:

    <HTTPTargetConnection>
        <Properties/>
        <URL>http://somehost.org/get</URL>
    </HTTPTargetConnection>
    
    or
    
    <HTTPTargetConnection>
        <Properties/>
        <URL>http://somehost.org:9080/get</URL>
    </HTTPTargetConnection>
    

السبب: إعداد غير صحيح للخادم الهدف

في حال إعداد الخادم الهدف بمنفذ آمن مثل 443 بدون تفعيل طبقة المقابس الآمنة، ثم يتسبب في إرسال معالج الرسائل في Apigee Edge طلبات HTTP إلى عنوان آمن الخادم الهدف الذي تم إعداده لبروتوكول أمان طبقة النقل (TLS) والذي أدى إلى حدوث هذه المشكلة.

التشخيص

اتّبِع الخطوات التالية لتشخيص الخطأ باستخدام أداة التتبُّع:

  1. فعِّل الإعداد Trace في واجهة مستخدم Apigee للخادم الوكيل لواجهة برمجة التطبيقات المتأثر.
  2. إرسال طلبات إلى الخادم الوكيل لواجهة برمجة التطبيقات
  3. اختَر أحد طلبات البيانات من واجهة برمجة التطبيقات التي تعذّر تنفيذها باستخدام رمز الاستجابة 400.
  4. انتقل خلال المراحل المختلفة وحدد مكان حدوث الفشل.
  5. ستظهر لك عادةً 400 استجابة الخطأ الواردة من خادم الخلفية. هذا يعني أنّه سيظهر لك ردّ الخطأ 400 في المرحلة تلقّي الردّ. من الخادم الهدف كما هو موضّح أدناه:

  6. تحديد نقطة النهاية المستهدفة التي تم تقديم الطلب من خلالها من خلال النقر على AX (البيانات المسجَّلة في "إحصاءات Google") في التتبّع.

  7. سجِّل قيمة target.name، التي تمثّل اسم نقطة النهاية المستهدَفة.

    في مثال ملف التتبُّع أعلاه، يكون target.name هو default. وهذا يشير إلى أن نقطة النهاية المستهدفة المستخدمة لهذا الطلب هي الإعداد الافتراضي.

  8. راجِع تعريف نقطة النهاية المستهدَفة لفهم الإعدادات.

    نموذج ضبط نقطة النهاية المستهدفة:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <TargetEndpoint name="default">
        <Description/>
        <FaultRules/>
        <PreFlow name="PreFlow">
            <Request/>
            <Response/>
        </PreFlow>
        <PostFlow name="PostFlow">
            <Request/>
            <Response/>
        </PostFlow>
        <Flows/>
        <HTTPTargetConnection>
            <Properties/>
            <LoadBalancer>
            <Server name="faulty-target"/>
            </LoadBalancer>
        </HTTPTargetConnection>
    </TargetEndpoint>
    

    يوضح المثال أعلاه من إعدادات نقطة النهاية المستهدفة أنك تستخدم خادمًا مستهدفًا تُسمَّى faulty-target.

  9. بعد حصولك على اسم الخادم الهدف، يمكنك استخدام إحدى الطرق التالية تحقَّق من إعدادات الخادم الهدف:

    • واجهة مستخدم Edge
    • واجهة برمجة تطبيقات الإدارة

واجهة مستخدم Edge

  1. انتقِل إلى Apigee Edge >. المشرف > البيئات > الخوادم المستهدفة.
  2. اختر الخادم المستهدف المحدد من الخادم الوكيل لواجهة برمجة التطبيقات وانقر على تعديل
  3. تحقَّق من المنفذ المحدّد للخادم الهدف ومعلومات طبقة المقابس الآمنة.
  4. في حال إعداد الخادم الهدف باستخدام منفذ آمن (مثل: 443): ولكن لم يتم تمكين طبقة المقابس الآمنة، فهذا هو سبب هذه المشكلة.

    كما ترى في لقطة الشاشة أعلاه، المنفذ المستخدَم هو 443 لكن طبقة المقابس الآمنة غير موجودة مفعَّل لهذا المنفذ في إعدادات الخادم الهدف. ظهور رسالة في Apigee Edge المعالج لإرسال طلبات HTTP إلى المنفذ الآمن 443. لذلك، تحصل على خطأ 400 Bad Request مع الرسالة The plain HTTP request was sent to HTTPS port.

واجهة برمجة تطبيقات الإدارة

  1. نفِّذ الحصول على واجهة برمجة تطبيقات الخادم الهدف للحصول على تفاصيل حول الإعدادات المحدّدة للخادم الهدف كما هو موضح أدناه:

    مستخدم Cloud العام:

    curl -v 'https://api.enterprise.apigee.com/v1/organizations/ORG_NAME/environments/ENV_NAME>/targetservers/TARGET_SERVER_NAME' \
    -H "Content-Type:application/xml" \
    -H "Authorization:Bearer $TOKEN"
    

    مستخدم Cloud خاص:

    curl -v 'http://MANAGEMENT_IP:8080/v1/organizations/ORG_NAME/environments/ENV_NAME/targetservers/TARGET_SERVER_NAME' \
    -H "Content-Type:application/xml" \
    -H "Authorization:Bearer $TOKEN"
    
  2. تحقَّق من المنفذ المحدّد للخادم الهدف ومعلومات طبقة المقابس الآمنة.
  3. إذا تم إعداد الخادم الهدف باستخدام منفذ آمن (على سبيل المثال: 443)، ولكن القسم SSLInfo غير محدد أو غير مفعّل، فإن هذا هو سبب هذه المشكلة.

    نموذج ضبط الخادم الهدف:

    {
      "host" : "somehost.org",
      "isEnabled" : true,
      "name" : "faulty-target",
      "port" : 443
    }
    

    في النموذج الناتج أعلاه، يمكننا أن نرى أن المنفذ المستخدم للاتصال المستهدف هو 443، ولكن ما مِن حظر للإعدادات SSLInfo.

    يؤدي هذا إلى إرسال معالج الرسائل في Apigee Edge إلى إرسال طلبات HTTP إلى المنفذ الآمن. 443 لذلك، ستحصل على الخطأ 400 Bad Request مع الرسالة The plain HTTP request was sent to HTTPS port

الدقة

فإذا كان الخادم المستهدف آمنًا أو مهيأًا باستخدام بروتوكول أمان طبقة النقل (TLS)، فإنك بحاجة إلى تمكين طبقة المقابس الآمنة (SSL) الخادم الهدف.

ويمكنك إجراء ذلك باستخدام أحد الخيارات التالية:

  • واجهة مستخدم Edge
  • واجهة برمجة تطبيقات الإدارة

واجهة مستخدم Edge

  1. انتقل إلى الخادم الهدف على Edge UI > المشرف > البيئات > الخوادم المستهدفة.
  2. اختَر الخادم الهدف المحدّد وانقر على تعديل.
  3. إذا كان الخادم الهدف آمنًا ويستخدم منفذًا مثل 443، يمكنك تفعيل طبقة المقابس الآمنة من خلال تحديد مربع الاختيار إلى جانب خيار طبقة المقابس الآمنة (SSL).
  4. اضبط Truststore وCiphers وProtocols. (عند الحاجة فقط)

واجهة برمجة تطبيقات الإدارة

استخدِم واجهة برمجة تطبيقات الإدارة لإعداد الخادم الهدف كما هو موضَّح في مستندات تعديل إعدادات الخادم الهدف

يجب جمع معلومات التشخيص

في حال استمرار المشكلة حتى بعد اتّباع التعليمات أعلاه، يُرجى جمع ما يلي معلومات التشخيص، ثم التواصل مع فريق دعم Apigee Edge.

  1. إذا كنت أحد مستخدمي السحابة الإلكترونية العامة، يُرجى تقديم المعلومات التالية:
    • اسم المؤسسة
    • اسم البيئة
    • اسم الخادم الوكيل لواجهة برمجة التطبيقات
    • أكمِل أمر curl لإعادة إنتاج الخطأ.
    • نتيجة أداة التتبُّع (إذا كنت قادرًا على التقاط الطلب الذي تعذّر تنفيذه)
  2. إذا كنت من مستخدمي السحابة الإلكترونية الخاصة، يُرجى تقديم المعلومات التالية:
    • تم ملاحظة رسالة الخطأ الكاملة
    • اسم البيئة
    • حزمة الخادم الوكيل لواجهة برمجة التطبيقات
    • تعريف الخادم الهدف (إذا كنت تستخدم الخادم الهدف في نقطة النهاية)
    • نتيجة أداة التتبُّع (إذا كنت قادرًا على التقاط الطلب الذي تعذّر تنفيذه)