این صفحه به‌وسیله ‏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
درخواست HTTP به یک نقطه پایانی هدف پیکربندی شده با TLS	درخواست HTTP به یک سرور پشتیبان با قابلیت TLS در نقطه پایانی هدف ارسال شده است.	کاربران فضای ابری عمومی و خصوصی Edge
پیکربندی نادرست سرور هدف	سرور هدف با پورت امن `443` پیکربندی شده است اما SSL فعال نیست.	کاربران فضای ابری عمومی و خصوصی Edge

علت: درخواست 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 به یک سرور backend با قابلیت TLS در نقطه پایانی هدف یک API Proxy به طور نادرست پیکربندی شده باشند.

تشخیص

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

قابلیت ردیابی (Trace) را در رابط کاربری Apigee برای پروکسی API آسیب‌دیده فعال کنید.
درخواست‌هایی را به پروکسی API ارسال کنید.
یکی از درخواست‌های API که با کد پاسخ 400 ناموفق بوده‌اند را انتخاب کنید.
مراحل مختلف را بررسی کنید و مشخص کنید که شکست در کجا رخ داده است.
معمولاً پاسخ خطای 400 را از سرور backend مشاهده خواهید کرد. یعنی، پاسخ خطای 400 را در مرحله پاسخ دریافتی از سرور هدف، همانطور که در زیر نشان داده شده است، مشاهده خواهید کرد:
با کلیک بر روی آیکون AX (داده‌های تحلیلی ثبت‌شده) در مسیر ردیابی، نقطه پایانی هدفی که درخواست برای آن ارسال شده است را تعیین کنید.
به target.url توجه کنید که شامل پروتکل، نام مستعار میزبان سرور backend و گاهی اوقات شماره پورت است. پورت مورد استفاده برای URL هدف 443 است اما پروتکل HTTP است.
برای درک پیکربندی، تعریف نقطه پایانی هدف را مرور کنید.
تأیید کنید که میزبان سرور backend امن است و به یک پورت امن مانند 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 است. این باعث می‌شود سرور backend با 400 Bad Request و پیام خطای The plain HTTP request was sent to HTTPS port پاسخ دهد.

وضوح تصویر

اگر سرور backend شما امن/دارای TLS فعال است، مطمئن شوید که از پروتکل https در عنصر <URL> نقطه پایانی هدف استفاده می‌کنید، همانطور که در مثال زیر نشان داده شده است:
نمونه پیکربندی نقطه پایانی هدف:
```
<HTTPTargetConnection>
    <Properties/>
    <URL>https://somehost.org:443/get</URL>
</HTTPTargetConnection>
```
نکته: هنگام استفاده از پروتکل HTTPS با پورت امن استاندارد 443 ، نیازی به ذکر شماره پورت نیست. در این مثال برای سهولت درک، از شماره پورت استفاده شده است.
اگر سرور backend شما امن نیست ، پس:
- شماره پورت امن مانند 443 را ذکر نکنید.
- اگر سرور backend شما به یک پورت استاندارد غیر امن گوش می‌دهد، اصلاً لازم نیست شماره پورت را ذکر کنید.
- اگر از پورت ناامن دیگری استفاده می‌کنید، شماره پورت را ذکر کنید، مثلاً: 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 را از سرور backend مشاهده خواهید کرد. یعنی پاسخ خطای 400 را در مرحله دریافت پاسخ از سرور هدف، همانطور که در زیر نشان داده شده است، مشاهده خواهید کرد:
با کلیک بر روی آیکون AX (داده‌های تحلیلی ثبت‌شده) در مسیر ردیابی، نقطه پایانی هدفی که درخواست برای آن ارسال شده است را تعیین کنید.
به 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 استفاده می‌کنید.

پس از اینکه نام سرور هدف را پیدا کردید، می‌توانید از یکی از روش‌های زیر برای بررسی پیکربندی سرور هدف استفاده کنید:
- رابط کاربری اج
- رابط برنامه‌نویسی کاربردی مدیریت

رابط کاربری اج

به 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 مربوط به سرور هدف (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"

کاربر ابر خصوصی:

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 را برای سرور هدف خاص فعال کنید.

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

رابط کاربری اج
رابط برنامه‌نویسی کاربردی مدیریت

رابط کاربری اج

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

رابط برنامه‌نویسی کاربردی مدیریت

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

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

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

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