הפסקות בהעלאה ב-HTTP ו-Expect: 100-continue

זהה את החילוף Expect: 100-continue והבחן בין נקודת ההחלטה הקצרה שלו לבין העלאה שנתקעה أثناء העברת נתונים.

החיבור נפתח. כותרות הבקשה יוצאות. נראה שהקובץ אינו זז. הסבר אחד הוא שהלקוח ממתין לתשובה ל-Expect: 100-continue לפני שהוא שולח את הגוף.

המנגנון מאפשר לנמען לדחות בקשה לפי הכותרות שלה לפני שנשלחת העלאה שעשויה להיות גדולה. הרצף המוצלח הרגיל הוא:

request headers → 100 Continue → request body → final response

100 הוא אינפורמטיבי: הוא מאפשר ללקוח להמשיך, אך אינו אומר שהקובץ נשמר או שהפעולה של היישום הצליחה. Git push שמחזיר HTTP 417 הוא מקרה קונקרטי אחד של ציפייה שנכשלה.

גלה איזו תשובה קיבל הלקוח

תצפיתמשמעות לבדיקה
100 Continueהלקוח יכול להמשיך עם הגוף
דחייה סופית לפני הגוףהפעולה נדחתה בשלב הכותרות
אין תשובת ביניים מצופהמדיניות ההמתנה של הלקוח והטיפול בנתיב הזה

curl מציע הגדרת המתנה ייעודית ל-expect-continue. אם המתנת libcurl הזו תפוג בלי התשובה המצופה, הוא שולח את הגוף בכל זאת; פקיעה אינה כישלון אוטומטי של כל ההעברה. ההגדרה נפרדת מהזמן המותר להעברה המלאה. הגדלת האחרון עשויה להשאיר את אותה הפסקה ראשונית ללא הסבר.

זהה גם איזו שיחת HTTP נושאת את Expect. ב-CONNECT רגיל ליעד HTTPS, החילוף של ההעלאה באתר נמצא בתוך TLS; פרוקסי קדמי אינו פשוט בוחן את כותרת הציפייה הפנימית שלו. נתיב יירוט או העברה בטקסט גלוי שונה.

הסרת הציפייה יכולה להיות בחירת תאימות מכוונת, אך פירושה שהלקוח עלול להתחיל לשלוח גוף גדול לפני שיידע על דחייה מוקדמת. השווה התנהגות זו לדרישה בפועל. אל תתאר מעקף היסטורי לפרוקסי ישן כהוראה אוניברסלית להסיר את הכותרת מכל העלאה.

מאמרים קשורים