דף זה תורגם על ידי 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 לנקודת קצה (endpoint) המוגדרת באמצעות TLS	בקשת HTTP נשלחה לשרת קצה עורפי שתומך ב-TLS בנקודת הקצה (endpoint) של היעד.	משתמשי Edge הציבוריים והפרטיים
הגדרה שגויה של שרת היעד	שרת היעד הוגדר עם יציאה מאובטחת `443` אבל SSL לא מופעל.	משתמשי Edge הציבוריים והפרטיים

הסיבה: בקשת HTTP למארח וירטואלי שהוגדר באמצעות TLS

השגיאה הזו מתרחשת כשלקוח מנסה להתחבר ל-API ב-Apigee, והמארח הווירטואלי שצוין מוגדר להשתמש ב-SSL ומקבל במקום זאת בקשת HTTP.

אבחון

הבעיה הזו מתרחשת בנקודת הקצה Northbound ובקשות ה-API נכשלות בנקודת הכניסה בין אפליקציית הלקוח לבין הנתב, ולכן הודעות השגיאה האלה לא נרשמות ביומני הגישה של נתב NGINX. לכן, הבקשות האלה לא יתועדו בכלים כמו API Monitoring וכלי המעקב.

צריך לאמת את בקשת ה-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 לנקודת קצה (endpoint) המוגדרת באמצעות TLS

השגיאה הזו מתרחשת אם הגדרת באופן שגוי בקשות HTTP לשרת קצה עורפי שתומך ב-TLS (אבטחת שכבת התעבורה) בנקודת הקצה של היעד של שרת proxy ל-API.

אבחון

כדי לאבחן את השגיאה באמצעות כלי המעקב, בצעו את השלבים הבאים:

מפעילים מעקב בממשק המשתמש של Apigee עבור שרת ה-API המושפע.
שליחת בקשות ל-API Proxy.
יש לבחור אחת מבקשות ה-API שנכשלו עם קוד התגובה 400.
אפשר לעבור בין השלבים השונים כדי להבין איפה קרה הכשל.
בדרך כלל, הודעת השגיאה 400 תופיע משרת הקצה העורפי. כלומר, תראו את תגובת השגיאה 400 בשלב התגובה שהתקבלה משרת היעד כפי שמוצג בהמשך:
כדי לקבוע מהי נקודת הקצה (endpoint) של היעד שעבורה נשלחה הבקשה, לוחצים על הסמל AX (רישום נתונים ב-Analytics) במעקב.
חשוב לשים לב ל-target.url, שמכיל את הפרוטוקול, את הכינוי של השרת העורפי ולפעמים את מספר היציאה. היציאה שמשמשת לכתובת ה-URL של היעד היא 443, אבל הפרוטוקול הוא HTTP.
כדי להבין את ההגדרה, כדאי לבדוק את ההגדרה של נקודת הקצה (endpoint) של היעד.
יש לוודא שמארח השרת של הקצה העורפי מאובטח ומאזין ביציאה מאובטחת כמו 443. אם נעשה שימוש בפרוטוקול כ-http ברכיב <URL>, זו הסיבה לבעיה.

הגדרה לדוגמה של נקודת קצה (endpoint):
```
<?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> של נקודת הקצה של היעד, כפי שמוצג בדוגמה הבאה:

הגדרה לדוגמה של נקודת קצה (endpoint):
```
<HTTPTargetConnection>
    <Properties/>
    <URL>https://somehost.org:443/get</URL>
</HTTPTargetConnection>
```
הערה: כשמשתמשים בפרוטוקול HTTPS עם יציאה מאובטחת רגילה 443, אין צורך לציין את מספר היציאה. בדוגמה הזו אנחנו משתמשים במספר היציאה כדי להבין טוב יותר.
אם שרת הקצה העורפי לא מאובטח, אז:
- אין לציין את מספר היציאה המאובטחת כמו 443.
- אין צורך לציין את מספר היציאה בכלל, אם השרת העורפי מאזין ליציאה רגילה לא מאובטחת
- יש לציין את מספר היציאה אם משתמשים ביציאה אחרת לא מאובטחת, לדוגמה: 9080
הגדרה לדוגמה של נקודת קצה (endpoint):
```
<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 (אבטחת שכבת התעבורה), שמוביל לבעיה הזו.

אבחון

כדי לאבחן את השגיאה באמצעות כלי המעקב, בצעו את השלבים הבאים:

מפעילים מעקב בממשק המשתמש של Apigee עבור שרת ה-API המושפע.
שליחת בקשות ל-API Proxy.
יש לבחור אחת מבקשות ה-API שנכשלו עם קוד התגובה 400.
אפשר לעבור בין השלבים השונים כדי להבין איפה קרה הכשל.
בדרך כלל תופיע הודעת השגיאה 400 כתגובה משרת הקצה העורפי. כלומר, תראו את תגובת השגיאה 400 בשלב התגובה שהתקבלה משרת היעד כפי שמוצג בהמשך:
כדי לקבוע מהי נקודת הקצה (endpoint) של היעד שעבורה נשלחה הבקשה, לוחצים על הסמל AX (רישום נתונים ב-Analytics) במעקב.
שימו לב ל-target.name, שמייצג את השם של נקודת הקצה של היעד.

בקובץ המעקב לדוגמה שלמעלה, הערך target.name הוא default. התווית מציינת שנקודת הקצה (endpoint) המשמשת כיעד לבקשה הזו מוגדרת כברירת מחדל.

כדי להבין את ההגדרה, כדאי לבדוק את ההגדרה של נקודת הקצה (endpoint) של היעד.

הגדרה לדוגמה של נקודת קצה (endpoint):

<?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.

אחרי שמאתרים את שם שרת היעד, אפשר לבדוק את ההגדרה של שרת היעד באמצעות אחת מהשיטות הבאות:
- ממשק המשתמש של Edge
- Management API

ממשק המשתמש של Edge

עוברים אל Apigee Edge > Admin > Environments > Target Servers.
בוחרים את שרת היעד הספציפי שזוהה משרת ה-API של ה-API ולוחצים על Edit.
מאמתים את היציאה שצוינה עבור שרת היעד ואת פרטי ה-SSL.
אם שרת היעד מוגדר עם יציאה מאובטחת (לדוגמה: 443), אבל SSL לא מופעל, זו הסיבה לבעיה.

כמו שאפשר לראות בצילום המסך שלמעלה, היציאה שבה נעשה שימוש היא 443 אבל SSL לא מופעל ביציאה הזו בהגדרה של שרת היעד. פעולה זו גורמת למעבד ההודעות של Apigee Edge לשלוח בקשות HTTP ליציאה המאובטחת 443. לכן, מתקבלת השגיאה 400 Bad Request עם ההודעה The plain HTTP request was sent to HTTPS port.

Management API

מפעילים את ה-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
Management API

ממשק המשתמש של Edge

עוברים לשרת היעד דרך Edge UI > אדמין > סביבות > שרתי יעד.
בוחרים את שרת היעד הספציפי ולוחצים על Edit.
אם שרת היעד מאובטח ומשתמש ביציאה כמו 443, צריך להפעיל SSL על ידי סימון התיבה שלצד האפשרות SSL.
מגדירים את Truststore , Ciphers ופרוטוקולים. (רק אם נדרש)

Management API

אפשר להשתמש ב-Management API כדי להגדיר את שרת היעד, כפי שמתואר במאמר בנושא עדכון ההגדרות של שרת היעד.

צריך לאסוף פרטי אבחון

אם הבעיה נמשכת גם אחרי שביצעתם את ההוראות שלמעלה, עליכם לאסוף את פרטי האבחון הבאים ולפנות לתמיכה של Apigee Edge.

אם אתם משתמשים ב-Public Cloud, תצטרכו לספק את הפרטים הבאים:
- שם הארגון
- שם הסביבה
- שם שרת proxy ל-API
- השלמה של פקודת curl לשחזור השגיאה
- פלט של כלי המעקב (אם הצלחתם לתעד את הבקשה שנכשלה)
אם אתם משתמשים בענן פרטי, תצטרכו לספק את הפרטים הבאים:
- נצפתה הודעת שגיאה מלאה
- שם הסביבה
- חבילת proxy ל-API
- הגדרת שרת היעד (אם משתמשים בשרת יעד בנקודת הקצה)
- פלט של כלי המעקב (אם הצלחתם לתעד את הבקשה שנכשלה)