המתינו לשורה הריקה שאחרי CONNECT
קראו את תגובת ה-HTTP/1 CONNECT המלאה לפני מסירת ה-socket ל-TLS, גם כששורת הסטטוס מגיעה ראשונה.
הלקוח רואה 200 Connection Established, מתחיל TLS ומיד מדווח על שטויות במקום שבו אמור להיות רשומת TLS. חפשו תגובת HTTP שלא הושלמה לפני שתולים את האשם בהגדרות ההצפנה של היעד.
בחילופי HTTP/1 CONNECT, שורת הסטטוס היא רק ההתחלה של התגובה. אחריה יכולים לבוא שדות כותרת. השורה הריקה שמסיימת את חלק הכותרות מסמנת את המעבר למנהרה אחרי תגובת CONNECT מוצלחת.
HTTP/1.1 200 Connection Established\r\n
Proxy-Agent: example\r\n
\r\n
הבתים האלה יכולים להגיע בקריאה אחת, בכמה קריאות, או בקריאה שמכילה גם בתים עוקבים. TCP אינו משמר את גבולות הכתיבה של השרת.
הפכו את המסירה למצב מפורש של המנתח
- אספו ונתחו את שורת הסטטוס. השתמשו בקוד המספרי ולא בביטוי סיבה אנגלי מדויק.
- המשיכו עד שהמסיים המלא של חלק הכותרות הגיע. שורת סטטוס מוצלחת אינה מעלימה את השדות שנותרו.
- בתגובת CONNECT מוצלחת, ראו בבית שמיד אחרי המסיים הזה את תחילת נתוני המנהרה. בתגובות אחרות, פעלו לפי הטיפול המתאים בתגובת HTTP ובאימות.
- העבירו את החיבור ואת כל הבתים שלא נוצלו דרך ממשק ה-I/O המכושש שהפרוטוקול הבא תומך בו.
השלב האחרון חשוב גם כשחיפוש המפריד טוב. קורא מכושש עשוי לצרוך מה-socket יותר ממה שהמנתח ביקש. התחלת TLS על ה-socket החשוף תוך נטישת אותו קורא עלולה להשאיר בתים במאגר הפרטי של הקורא.
השתמשו במועד אחרון להקמה ובמגבלת גודל כותרות. EOF לפני המסיים הוא תגובת פרוקסי לא שלמה, לא הזמנה להמתין לנצח או לנסות TLS בכל זאת.
חשבו דרך כמה גבולות
דמיינו קריאה שמסתיימת אחרי Proxy-Agent:. המנתח עדיין זקוק לעוד בתי כותרת של HTTP. דמיינו קריאה נוספת שמסתיימת באמצע רצף ה-CRLF האחרון. זה עדיין לא חלק כותרות מלא. עכשיו דמיינו חלק כותרות מוצלח ומלא שאחריו בתים של מנהרה באותו מאגר: הבתים הנוספים האלה חייבים לשרוד את המסירה.
407 הוא תוצאה אחרת. הוא דורש טיפול באימות; הוא אינו מתיר TLS ClientHello לתוך מנהרה שמעולם לא נפתחה.
העדיפו מחבר מתוחזק אלא אם יישום לחיצת היד הוא המשימה. הגבול הזה ספציפי לחילופי ה-HTTP/1 שמוצגים כאן. פרוקסי HTTP/2 נושא CONNECT על זרם עם מסגור אחר.