מטפלי CONNECT של Node.js חייבים לשמר את מאגר head
טפלו בסוקט CONNECT ובמאגר head של Node בגבול שבין HTTP למנהרה, תוך שמירה על הבתים שכבר נקראו מעבר לכותרים.
שרת HTTP של Node מטפל בבקשת פרוקסי רגילה דרך פונקציית הקריאה החוזרת של הבקשה. CONNECT הולך בדרך אחרת: השרת פולט connect יחד עם הבקשה, סוקט הלקוח ומאגר head.
אירוע זה הוא המסירה בין ניתוח HTTP למנהרה. אין אובייקט ServerResponse רגיל להמשיך ולהשתמש בו לתעבורת המנהרה.
| ארגומנט | מה הוא נושא |
|---|---|
req | בקשת CONNECT, כולל סמכות היעד והכותרים שלה |
clientSocket | החיבור חזרה אל הלקוח |
head | נתוני מנהרה ש-Node כבר קרא מעבר לכותרי HTTP, ייתכן שריקים |
השלימו את החלטת HTTP לפני העברת בתים
אמתו את המארח והפורט המבוקשים, החילו את מדיניות הגישה והאימות של הפרוקסי, והקימו את החיבור במעלה הזרם. CONNECT מזהה סמכות כמו service.example:443; נתחו את הצורה הזו תוך התחשבות בסמכויות IPv6 במקום לפצל באופן עיוור בכל נקודתיים.
כאשר המנהרה מתקבלת, שלחו את תגובת ה-HTTP המוצלחת ואחריה השורה הריקה המסיימת שלה. לאחר מכן העבירו כל בתי head במעלה הזרם לפני שממשיכים בבתים מאוחרים יותר מסוקט הלקוח. חיבור מאזין נתונים חדש אינו יכול לשחזר מאגר שכבר נמסר בנפרד למטפל.
הדוגמה הרשמית של Node למנהרות מבצעת את המסירה הזו באמצעות serverSocket.write(head) לפני חיבור שני כיווני הזרם. הדוגמה הקטנה שלה ממחישה את המעבר; פרוקסי פרוס זקוק גם לניסיונות חיבור מוגבלים, בקרות גישה וטיפול במחזור חיים.
לאחר הצלחה, הבתים שייכים לפרוטוקול השירות
תגובת CONNECT מוצלחת הופכת את החיבור לזרם בתים. אם היעד הוא אתר HTTPS, חילופי ה-TLS שלו נוסעים בתוך אותו זרם. רק לתמלל אותו אינו מחייב את הפרוקסי להנפיק תעודת אתר חלופית.
לפני קבלת CONNECT, שגיאת HTTP יכולה להסביר מדוע סורבה. לאחר הקבלה, כתיבת HTTP 500 לתוך הזרם תזריק בתים לפרוטוקול המנהרה. במקום זאת, סיימו או השמידו את החיבורים המתאימים בכשלים מאוחרים יותר.
חברו את שני הכיוונים עם טיפול בזרם מודע ללחץ חוזר, והחליטו כיצד אירועי end, error ו-close מסיימים את העמית. שמרו על מאגר ה-head הראשוני כחלק מאותו מודל בעלות; אלו נתוני יישום, לא כותרי HTTP מיותרים לזרוק.