این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

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` پیکربندی شده است اما SSL فعال نیست.	کاربران Edge Public و Private Cloud

علت: درخواست HTTP به یک میزبان مجازی با پیکربندی TLS

این خطا زمانی رخ می دهد که یک کلاینت در حال تلاش برای اتصال به یک API در Apigee است و میزبان مجازی ذکر شده برای استفاده از SSL پیکربندی شده است و به جای آن یک درخواست HTTP دریافت می کند.

تشخیص

از آنجایی که این مشکل در نقطه پایانی Northbound رخ می دهد و درخواست های API در تعامل نقطه ورودی بین برنامه مشتری و روتر با شکست مواجه می شوند، این پیام های خطا در گزارش های دسترسی روتر NGINX ثبت نمی شوند. بنابراین، این درخواست‌ها در ابزارهایی مانند API Monitoring و ابزار Trace ثبت نمی‌شوند.

درخواست API خود را تأیید کنید و ببینید آیا درخواست HTTP را برای نام مستعار میزبانی که برای پذیرش درخواست‌ها فقط در پورت امن 443 پیکربندی شده است، ارسال می‌کنید. اگر چنین است، پس دلیل این موضوع است.
نمونه درخواست API نادرست:
```
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>
```
در درخواست نمونه بالا، توجه داشته باشید که یک درخواست HTTP به میزبان مستعار myorg-test.apigee.net در پورت امن 443 ارسال می شود. این دلیل خطای 400 Bad Request است.

قطعنامه

باید بررسی کنید که آیا مشتری به جای HTTP از HTTP استفاده می کند یا خیر و درخواست صحیح را مطابق شکل زیر انجام دهید:

نمونه درخواست API:

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

توجه: هنگام استفاده از پروتکل HTTPS با پورت ایمن استاندارد 443 ، همانطور که در درخواست نمونه بالا نشان داده شده است، به شماره پورت نیازی نیست.

علت: درخواست HTTP به نقطه پایانی هدف پیکربندی شده با TLS

این خطا در صورتی رخ می‌دهد که درخواست‌های HTTP را برای یک سرور باطنی فعال‌شده با TLS در نقطه پایانی یک پروکسی API به اشتباه پیکربندی کرده باشید.

تشخیص

از مراحل زیر برای تشخیص خطا با استفاده از ابزار Trace استفاده کنید:

Trace را در رابط کاربری Apigee برای پروکسی API آسیب دیده فعال کنید.
به پروکسی API درخواست دهید.
یکی از درخواست های API که با کد پاسخ 400 ناموفق بود را انتخاب کنید.
در مراحل مختلف پیمایش کنید و تعیین کنید که در کجا شکست رخ داده است.
معمولاً پاسخ خطای 400 را خواهید دید که از سرور باطن می آید. یعنی پاسخ خطای 400 را در فاز Response دریافت شده از سرور هدف مطابق شکل زیر مشاهده خواهید کرد:
با کلیک بر روی نماد AX (Analytics Recorded) در ردیابی، نقطه پایانی هدفی را که درخواست برای آن ارسال شده است، تعیین کنید.
به target.url توجه کنید که حاوی پروتکل، نام مستعار میزبان سرور باطن و گاهی شماره پورت است. پورت مورد استفاده برای URL هدف 443 است اما پروتکل HTTP است.
برای درک پیکربندی، تعریف نقطه پایانی هدف را مرور کنید.
بررسی کنید که میزبان سرور پشتیبان ایمن است و در یک پورت امن مانند 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 .

قطعنامه

اگر سرور پشتیبان شما ایمن است/TLS فعال است، پس مطمئن شوید که از پروتکل به عنوان https در عنصر <URL> نقطه پایانی هدف استفاده می کنید، همانطور که در مثال زیر نشان داده شده است:
نمونه پیکربندی نقطه پایانی هدف:
```
<HTTPTargetConnection>
    <Properties/>
    <URL>https://somehost.org:443/get</URL>
</HTTPTargetConnection>
```
توجه: هنگام استفاده از پروتکل HTTPS با پورت امن استاندارد 443 ، نیازی به ذکر شماره پورت نیست. شماره پورت در این مثال برای سهولت درک استفاده شده است.
اگر سرور پشتیبان شما ایمن نیست ، پس:
- به شماره پورت امن مانند 443 اشاره نکنید.
- اگر سرور باطن شما به یک پورت استاندارد غیر ایمن گوش می دهد، اصلاً لازم نیست شماره پورت را ذکر کنید
- اگر از هر پورت غیر ایمن دیگری استفاده می کنید، شماره پورت را ذکر کنید، به عنوان مثال: 9080
نمونه پیکربندی نقطه پایانی هدف:
```
<HTTPTargetConnection>
    <Properties/>
    <URL>http://somehost.org/get</URL>
</HTTPTargetConnection>

or

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

علت: پیکربندی سرور هدف نادرست است

اگر سرور هدف با یک پورت امن مانند 443 بدون فعال کردن SSL پیکربندی شده باشد، باعث می‌شود که پردازشگر پیام Apigee Edge درخواست‌های HTTP را به یک سرور هدف امن یا پیکربندی شده با TLS ارسال کند که منجر به این مشکل می‌شود.

تشخیص

از مراحل زیر برای تشخیص خطا با استفاده از ابزار Trace استفاده کنید:

Trace را در رابط کاربری Apigee برای پروکسی API آسیب دیده فعال کنید.
به پروکسی API درخواست دهید.
یکی از درخواست های API که با کد پاسخ 400 ناموفق بود را انتخاب کنید.
در مراحل مختلف پیمایش کنید و تعیین کنید که در کجا شکست رخ داده است.
معمولاً پاسخ خطای 400 را خواهید دید که از سرور باطن می آید. یعنی پاسخ خطای 400 را در فاز Response دریافت شده از سرور مورد نظر مطابق شکل زیر خواهید دید:
با کلیک بر روی نماد AX (Analytics Recorded) در ردیابی، نقطه پایانی هدفی را که درخواست برای آن ارسال شده است، تعیین کنید.
به target.name توجه کنید که نشان دهنده نام نقطه پایانی هدف است.
در فایل ردیابی مثال بالا، target.name پیش فرض است. این نشان می دهد که نقطه پایانی مورد استفاده برای این درخواست پیش فرض است.

برای درک پیکربندی، تعریف نقطه پایانی هدف را مرور کنید.

نمونه پیکربندی نقطه پایانی هدف:

<?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 استفاده می کنید.

هنگامی که نام سرور مورد نظر را دارید، می توانید از یکی از روش های زیر برای بررسی پیکربندی سرور مورد نظر استفاده کنید:
- رابط کاربری لبه
- مدیریت API

رابط کاربری لبه

به Apigee Edge > Admin > Environments > Target Servers بروید.
سرور مورد نظر مشخص شده از پروکسی API را انتخاب کنید و روی ویرایش کلیک کنید.
پورت مشخص شده برای سرور مورد نظر و اطلاعات SSL را بررسی کنید.
اگر سرور هدف با یک پورت امن پیکربندی شده است (به عنوان مثال: 443 )، اما SSL فعال نیست، دلیل این مشکل همین است.
همانطور که در تصویر بالا می بینید، پورت استفاده شده 443 است اما SSL برای آن پورت در پیکربندی سرور هدف فعال نیست. این باعث می شود که پردازشگر پیام Apigee Edge درخواست های HTTP را به پورت امن 443 ارسال کند. بنابراین، با خطای 400 Bad Request با پیغام The plain HTTP request was sent to HTTPS port مواجه می شوید.

مدیریت API

Get target server API را اجرا کنید تا جزئیات مربوط به پیکربندی سرور هدف خاص را مطابق شکل زیر دریافت کنید:

کاربر عمومی ابر:

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"

پورت مشخص شده برای سرور مورد نظر و اطلاعات SSL را بررسی کنید.
اگر سرور مورد نظر با یک پورت امن پیکربندی شده است (به عنوان مثال: 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 را برای سرور هدف خاص فعال کنید.

با استفاده از یکی از گزینه های زیر می توانید این کار را انجام دهید:

رابط کاربری لبه
مدیریت API

رابط کاربری لبه

به سرور مورد نظر در Edge UI > Admin > Environments > Target Servers بروید.
سرور مورد نظر خاص را انتخاب کنید و روی ویرایش کلیک کنید.
اگر سرور مورد نظر شما امن است و از پورتی مانند 443 استفاده می‌کند، SSL را با انتخاب کادر کنار گزینه SSL فعال کنید.
Truststore ، رمزها و پروتکل ها را پیکربندی کنید. (فقط در صورت نیاز)

مدیریت API

از API مدیریت برای پیکربندی سرور هدف همانطور که در مستندات پیکربندی سرور هدف به روز رسانی توضیح داده شده است استفاده کنید.

باید اطلاعات تشخیصی را جمع آوری کرد

اگر حتی پس از پیروی از دستورالعمل‌های بالا، مشکل همچنان ادامه داشت، اطلاعات تشخیصی زیر را جمع‌آوری کنید و سپس با پشتیبانی Apigee Edge تماس بگیرید.

اگر کاربر Public Cloud هستید، اطلاعات زیر را ارائه دهید:
- نام سازمان
- نام محیط زیست
- نام پروکسی API
- برای بازتولید خطا، دستور curl را کامل کنید
- خروجی ابزار ردیابی (اگر توانسته اید برای درخواست ناموفق عکس بگیرید)
اگر کاربر Private Cloud هستید، اطلاعات زیر را ارائه دهید:
- پیغام خطای کامل مشاهده شد
- نام محیط زیست
- بسته پروکسی API
- تعریف سرور هدف (اگر از سرور هدف در نقطه پایانی خود استفاده می کنید)
- خروجی ابزار ردیابی (اگر توانسته اید برای درخواست ناموفق عکس بگیرید)