שמירה על נתונים שנצברו במאגר לאחר תגובת HTTP CONNECT

עטיפת פרוקסי קטנה יכולה לעבוד עם HTTPS ואז להיתקע כשמשתמשים בה שוב בפרוטוקול שהשרת שלו מדבר ראשון. השורה החשודה היא לרוב זו שממתינה לכך שמאגר הקליטה יסתיים ב-\r\n\r\n.

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

מצאו את הגבול בתוך המאגר

עבור החלפת HTTP/1.1 CONNECT, צברו בתים עד שסימן סיום הכותרות מופיע בכל מקום במאגר. פצלו בהופעה הראשונה שלו. נתחו את שורת הסטטוס ואת הכותרות מהחלק הראשון; שמרו בנפרד את כל מה שאחרי הגבול. החילו מגבלת גודל כותרות וזמן קצוב בזמן ההמתנה, והתייחסו לקריאת socket ריקה כאל חיבור סגור ולא כהזמנה נוספת ללולאה.

תגובת 2xx מוצלחת וסופית מחליפה את החיבור למצב מנהרה מיד לאחר הכותרות האלה. הבתים שאחריה הם כבר בתים של מנהרה. אל תזרקו אותם, אל תמתינו לגוף תגובת CONNECT, ואל תפרשו שדה Content-Length כרשות לצרוך חלק מהפרוטוקול החדש. תגובות מידע, אם קיימות, צריכות להיות מטופלות לפני התגובה הסופית הזו.

העטיפה חייבת להעביר את השאריות שלה

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

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

זה חשוב במיוחד כאשר מתאימים לקוח FTP או SSH דרך פרוקסי HTTP. הפרוקסי חייב גם להתיר את פורט היעד שהתבקש, ו-FTP עשוי להזדקק לחיבורי נתונים נוספים. ניתוח כותרות נכון פותר את מסירת הזרם; הוא אינו יכול להעניק הרשאת CONNECT או לספק את הערוץ השני של FTP.